upsampling (universo LMS/Squeezelite/Squeezeplay)

[marcoc1712]

come dicevo tempo addietro, uno stream (o un file) non è che una sequenza di bit. Che potrebbe rappresentare qualsiasi cosa: un brano musicale, una immagine, un filmato... o l'eseguibile di un programma.

Se non ho una "chiave di lettura" che mi dica esattamente come devo "raggruppare" ed interpretare i bit che compongono lo stream (o il file), quei bit non sono altro che quello: una sequenza di numeri binari del tutto priva di senso. Non ho assolutamente nessun modo per capire che cosa rappresentino!

Anche sapendo a priori che quello stream (o quel file) rappresenta uno stream PCM, l'informazione è incompleta ed assolutamente insufficiente: uno stream PCM "raw" (headerless) a 192K è del tutto indistinguibile da uno a 44.1K. Così come è altrettanto impossibile capire se si ha a che fare con uno stream composto da uno, due o più canali, se i campioni sono a 16 piuttosto che a 24 o 32 bit, se questi sono codificati come numeri interi o "reali" (floating point), big-endian o little-endian, ecc, ecc.

Anziché chiamare flac e/o sox, in quella riga di comando potrei anche metterci un bel "cat /dev/random", ed anche quello (uno stream composto da una sequenza casuale di bit) sarebbe del tutto indistinguibile da uno stream audio PCM raw!

La domanda quindi è: come accidenti fa LMS a sapere qual è il formato dei dati che gli vengono mandati indietro dai comandi esterni? (ad es. dopo l'upsampling?)

Le uniche cose sensate che LMS potrebbe fare avendo a che fare con uno stream PCM "raw" (headerless) sono:

1) imporre che gli stream che riceve "di ritorno" dai comandi esterni (se PCM) abbiano tutti, sempre e solo un ben preciso formato (predeterminato).

2) assumere che lo stream in uscita abbia sempre esattamente lo stesso formato dello stream in ingresso.

In entrambi i casi, per ovvi motivi ciò escluderebbe qualsiasi possibilità di fare resampling (o qualsiasi altra elaborazione che alteri il formato dello stream).

Oppure... oppure, c'è solo un'altra possibilità. Brutta, sporca, oscena, limitata e limitante, portatrice di bug e di problemi infiniti... in una parola semplicemente indecente:

3) che LMS interpreti le righe di comando (dei comandi esterni) che vengono inserite nel suo file di configurazione e ricavi da quelle il formato da utilizzare! :o

Se così fosse, si spiegherebbe come ha fatto a funzionarti... ed al tempo stesso perché i comandi esterni sembrano funzionare solo con ben determinate righe di comando e non con altre, pur perfettamente lecite (e magari anche più "logiche").

(ma mi rifiuto di crederlo. Se così fosse... non avrei parole: LMS non sarebbe un software decente, ma solo uno sporco "hack", semplicemente osceno e indecente, che non avrebbe mai dovuto essere distribuito. Tanto meno come prodotto commerciale o giù di li).

Per farla breve, LMS NON imposta MAI i valori del resample, lo lascia fare al convert.conf e/o alla combinazione delle richieste li specificate, le specifiche dei singoli formati e le capacità di rendering dei diversi modelli di lettore, mediante una complicata serie di incroci tra tabelle di definizione delle capability dei diversi modelli di lettore, le caratteristiche dei formati e le specifiche richieste.

Come scrivevo, è ovvio che il focus era il downsample, al fine di poter gestire lettori con limitate capacità di formato (es. solo MP3) e/o di bitrate (banda), tant'è che di sample rate in se tratta raramete, in questo senso LMS fa da broker tra le richieste del convert.conf ed i codec disponibili, nulla di più.

In nessun modo 'interpreta' le righe di comando, però prevede che queste siano scritte in conformità al 'suo' standard, quindi utilizzando le variabili ed i comandi di sostituzione che mette a disposizione, utilizzando al di fuori di queste limitazioni in alcuni casi funziona in altri ...non proprio...

Ovviamente non è come per 2) altrimenti non funzionerebbe in nessun caso l'upsampling o il downsampling, ma è certamente così nei casi in cui il formato di uscita è PCM.

c
Azz, Marco, ma è OVVIO!

Per il motivo di cui sopra: PCM (raw) non ha header, per cui LMS semplicemente NON ha nessun modo per sapere quale sia il formato dei dati che gli "ritornano" dal comando esterno!

Si, questo lo capisco e capisco anche che a LMS non importi nemmeno saperlo, lui si limita a passare lo stream come dati e scambiare una serie di messaggi di protocollo con i lettori, tra i quali quello che contiene l'url del file di origine.

Ma i lettori devono pur interpretare lo stream... Allora perchè usare due meccanismi diversi? Perchè non passare direttamente il WAV/AIF con l'header esattamente come avviene per il flac?

Probabilmente è un retaggio del passato.

[UnixMan]

Per farla breve, LMS NON imposta MAI i valori del resample, lo lascia fare al convert.conf e/o alla combinazione delle richieste li specificate, le specifiche dei singoli formati e le capacità di rendering dei diversi modelli di lettore, mediante una complicata serie di incroci tra tabelle di definizione delle capability dei diversi modelli di lettore, le caratteristiche dei formati e le specifiche richieste.

mi pare abbastanza ovvio dato che (per quanto mi è parso di capire) LMS non processa autonomamente i files/stream audio ma si limita a trasferirli, al più lasciando che ad occuparsi di eventuali conversioni che si rendano necessarie siano i comandi esterni definiti nel "convert.conf".

In nessun modo 'interpreta' le righe di comando, però prevede che queste siano scritte in conformità al 'suo' standard, quindi utilizzando le variabili ed i comandi di sostituzione che mette a disposizione, utilizzando al di fuori di queste limitazioni in alcuni casi funziona in altri ...non proprio...

questo invece è da chiarire, perché quello che dici qui sopra mi pare piuttosto contraddittorio. Le possibilità sono due:

A) LMS interpreta i comandi esterni definiti nel "convert.conf", che quindi devono seguire una sintassi ben precisa e sono limitati a quelli previsti;

B) LMS non cerca di "interpretare" i comandi definiti nel "convert.conf" ma li esegue così come sono, con una chiamata a "system()" (o simili), limitandosi a sostituire le eventuali "meta-variabili" presenti ed a gestire l'I/O della pipeline esterna (attraverso stdin ed stdout).

Il caso A) sarebbe a dir poco peculiare (ed indecente). Se fosse così ci sarebbe ben poco da sbizzarrirsi: a meno di non modificare il codice di LMS, puoi fare solo ciò che è stato previsto dagli sviluppatori e praticamente niente altro (se qualcosa di diverso da quanto previsto dovesse funzionare, praticamente lo farebbe "per sbaglio": sarebbe niente altro che l'exploit di un bug!).

Il caso B) è invece la cosa più sensata, nonché ciò che fanno praticamente tutti i software che utilizzano comandi esterni in modo analogo (e mi aspetterei che sia così anche per LMS). In tal caso il comando esterno che processa il file (o lo stream) può essere una qualsiasi "pipeline" composta da una sequenza di comandi qualsiasi che fanno qualsiasi cosa, a patto ovviamente che siano rispettate alcune "convenzioni" per quanto riguarda la gestione "dell'interfaccia" tra questi ed LMS, cioè la gestione (ed i formati) di input ed output da e verso LMS.

Ovviamente non è come per 2) altrimenti non funzionerebbe in nessun caso l'upsampling o il downsampling, ma è certamente così nei casi in cui il formato di uscita è PCM.

anche questo è abbastanza ovvio!

Se usi un formato "autodescrittivo" (come wav, aif, flac, mp3, ecc), che include un "magic number" che ne permette l'identificazione ed un header che ne descrive esaustivamente il contenuto (ed il renderer cui è destinato supporta tale formato), LMS non ha motivo di fare assolutamente nulla: può tranquillamente inviare i files (o gli stream) così come sono al renderer, lasciando che sia questo ad occuparsi del resto.

Se al contrario usi un formato PCM "raw", LMS deve necessariamente sapere con cosa ha a che fare (la descrizione esatta e completa del formato dello stream) ed altrettanto necessariamente anche il renderer deve essere in possesso di tale informazione, senza la quale non potrebbe essere in grado di interpretare lo stream (o file che sia).

[ formato dei dati che "ritornano" ad LMS dal comando esterno ]

Si, questo lo capisco e capisco anche che a LMS non importi nemmeno saperlo,

solo nel caso abbia a che fare con formati autodescrittivi, però: se ha a che fare con "pcm" (raw), dovrebbe importargli eccome! Non fosse altro perché si tratta di una informazione fondamentale da passare ai "lettori" (player o renderer che dir si voglia), senza la quale questi non potrebbero funzionare.

Ma i lettori devono pur interpretare lo stream... Allora perchè usare due meccanismi diversi? Perchè non passare direttamente il WAV/AIF con l'header esattamente come avviene per il flac?

bella domanda. In effetti, parrebbe la cosa più semplice e sensata da fare. Non ho idea del perché si comporti diversamente.

Però, ora che ci penso, mi sovviene un vago ricordo... non tutti i formati ("container") di file audio (pcm) sono "streamable" e, se ricordo bene, il "WAV" è uno di questi!

Infatti, da una rapida ricerca, leggo: "wav file format is not streamable".

Se è così, forse si spiega perché LMS può passare ai player un file wav "as-is" ma non spedirgli uno stream elaborato/generato al volo in formato wav (in realtà probabilmente potrebbe anche farlo, ma sarebbe una violazione dello standard che in alcuni casi potrebbe anche non funzionare).

Ora si tratta di capire se lo stesso vale anche per AIFF oppure no. Nessuno ha mai provato ad usare "aif" anziché wav (o pcm) per l'output?

[marcoc1712]

...ora che ci penso, mi sovviene un vago ricordo... non tutti i formati ("container") di file audio (pcm) sono "streamable" e, se ricordo bene, il "WAV" è uno di questi!

Infatti, da una rapida ricerca, leggo: "wav file format is not streamable".

Se è così, forse si spiega perché LMS può passare ai player un file wav "as-is" ma non spedirgli uno stream elaborato/generato al volo in formato wav (in realtà probabilmente potrebbe anche farlo, ma sarebbe una violazione dello standard che in alcuni casi potrebbe anche non funzionare).

BINGO, questo è quello che non spiegavo e mi hai dato la spiegazione,

...Ora si tratta di capire se lo stesso vale anche per AIFF oppure no. Nessuno ha mai provato ad usare "aif" anziché wav (o pcm) per l'output?

Si, uscire semplicemente in AIF invece che pcm ( -t aif) non funziona, Squeezelite applica comunque il processo riservato a pcm, quindi accede al file originario, esattamente come per wav e NON si aspetta sia presente l'header, motivo per cui uscendo con -t wav o -t aif da un comando wav pcm * * genera errore.

Sto sperimentando altre strade, se ricordi mi ero accorto che su mac e su win lo stesso comando dava esiti differenti e questo è probabilmente dovuto al fatto che la differenza tra wav e aif è solo il big endian, che su mac è standard, contrariamente a win.

Temo però che mi arenerò all'ingresso di squeezelite: se ritiene di ricevere un pcm, legge l'header dal file di origine.

.
questo invece è da chiarire, perché quello che dici qui sopra mi pare piuttosto contraddittorio. Le possibilità sono due:

A) LMS interpreta i comandi esterni definiti nel "convert.conf", che quindi devono seguire una sintassi ben precisa e sono limitati a quelli previsti;

B) LMS non cerca di "interpretare" i comandi definiti nel "convert.conf" ma li esegue così come sono, con una chiamata a "system()" (o simili), limitandosi a sostituire le eventuali "meta-variabili" presenti ed a gestire l'I/O della pipeline esterna (attraverso stdin ed stdout).

Il caso A) sarebbe a dir poco peculiare (ed indecente). Se fosse così ci sarebbe ben poco da sbizzarrirsi: a meno di non modificare il codice di LMS, puoi fare solo ciò che è stato previsto dagli sviluppatori e praticamente niente altro (se qualcosa di diverso da quanto previsto dovesse funzionare, praticamente lo farebbe "per sbaglio": sarebbe niente altro che l'exploit di un bug!).

Il caso B) è invece la cosa più sensata, nonché ciò che fanno praticamente tutti i software che utilizzano comandi esterni in modo analogo (e mi aspetterei che sia così anche per LMS). In tal caso il comando esterno che processa il file (o lo stream) può essere una qualsiasi "pipeline" composta da una sequenza di comandi qualsiasi che fanno qualsiasi cosa, a patto ovviamente che siano rispettate alcune "convenzioni" per quanto riguarda la gestione "dell'interfaccia" tra questi ed LMS, cioè la gestione (ed i formati) di input ed output da e verso LMS.

E' più o meno B), ma LMS mette a disposizione dei comandi esterni alcune variabili che possono essere utilizzate in riga di comando mediante convert,conf (v. la sua header).

Puoi usarli o meno, ma lui ragiona su quelli. Convert.conf contiene delle 'richieste' che LMS confronta con delle 'capacità' cercando le abbinate migliori per costruire un 'transcoder' cioè l'insieme di istruzioni (tra cui il comando) mediante il quale dall'input originario (che può essere un file, ma anche uno stream http o altro) lms porta all'ingresso del player lo stream fornito dal comando. Queste opzioni sono espresse nella prima riga (tipicamente #FT...), NON nelle righe di comando.

Ovvio che puoi costruire comandi contradditori che allora in alcuni casi funzionano, perchè comunque l'output è formalmente corretto ed autosuffciente, in altri no, perchè cerchi di far fare al player cose che non è progettato per fare 'ingannando' lms (es. -t wav in un comando wav > pcm).

[UnixMan]

[...]questo è probabilmente dovuto al fatto che la differenza tra wav e aif è solo il big endian

no. Anche se entrambi possono contenere un "payload" costituito da uno stream PCM, WAV ed AIFF sono due "container" sensibilmente diversi tra loro.

Si, uscire semplicemente in AIF invece che pcm ( -t aif) non funziona, Squeezelite applica comunque il processo riservato a pcm, quindi accede al file originario, esattamente come per wav e NON si aspetta sia presente l'header, motivo per cui uscendo con -t wav o -t aif da un comando wav pcm * * genera errore.

cosa che sarebbe ovvia... non fosse che, se non ricordo male, mi pare avessimo stabilito che per LMS "pcm" non significa "PCM raw", ma è una sorta di "meta-formato" che può essere indifferentemente wav, aif o raw PCM.

Comunque sia, non intendevo dire di uscire in aiff con una entry "wav pcm * *", ma piuttosto con una entry "wav aif * *".

Apparentemente, nel file di configurazione di default esiste già qualcosa del genere... solo che i comandi escono in raw PCM!!!

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

ogg aif * *
        [sox] -q -t ogg $FILE$ -t raw -r 44100 -c 2 -2 -s $-x$ -

mpc aif * *
        # IR
        [mppdec] --raw-be --silent --prev --gain 2 - -

(questa è una roba a dir poco imbarazzante... indecente... LMS mi piace sempre meno).

Comunque (se non è stato già fatto) si può provare a vedere che succede se si esce in aiff in una entry di tipo "flc aif * *".

E' più o meno B), ma LMS mette a disposizione dei comandi esterni alcune variabili che possono essere utilizzate in riga di comando mediante convert,conf (v. la sua header).

sì, quello l'avevo visto... (sono quelle che ho chiamato "meta-variabili"). Nulla di più di una sostituzione. Quella è una pratica furba, comoda e (relativamente) comune.

Puoi usarli o meno, ma lui ragiona su quelli. Convert.conf contiene delle 'richieste' che LMS confronta con delle 'capacità' cercando le abbinate migliori per costruire un 'transcoder' cioè l'insieme di istruzioni (tra cui il comando) mediante il quale dall'input originario (che può essere un file, ma anche uno stream http o altro) lms porta all'ingresso del player lo stream fornito dal comando.

sì, questo è chiaro.

Queste opzioni sono espresse nella prima riga (tipicamente #FT...), NON nelle righe di comando.

OK. Fin dal principio ero convinto che fosse così (dato il formato del file di configurazione, è la cosa più logica). Ma mi avevi fatto venire dei dubbi in merito... 8-)

Tornando al file di configurazione, alle "meta-variabili" (o comunque le si voglia chiamare) ed alle definizioni delle entries (#FT o quello che sia), ho notato che nel file di configurazione di default ci sono delle entries che fanno resampling, e queste usano una apposita "capability", "D", nonché una apposita coppia di meta-variabili: "%d" o "%D" e "RESAMPLE". Ad es.:

flc mp3 * *
        # FB:{BITRATE=--abr %B}T:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=--resample %D}
        [flac] -dcs $START$ $END$ -- $FILE$ | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

sfortunatamente il meccanismo sembra essere "monodirezionale", cioè pensato per il caso in cui è LMS stesso che "decide" quale debba essere il S/R di destinazione, sostituisce il relativo valore a "%d" o "%D" e quindi lo passa al comando esterno attraverso la sostituzione della variabile "$RESAMPLE$".

Se è così, c'è ben poco da fare. A meno che LMS non preveda anche la possibilità di mettere in "RESAMPLE" un valore arbitrario fisso (anziché usare "%d" o "%D"), ed in tal caso legga da lì il valore del S/R "di uscita" da comunicare al player.

Purtroppo però questo mi pare a dir poco improbabile: a quanto vedo, in "RESAMPLE" ci va una stringa con l'opzione specifica per il comando utilizzato e non (solo) il "target" S/R. Il che vorrebbe dire che per poter leggere da quella "variabile" il S/R desiderato, LMS dovrebbe interpretare correttamente una stringa sconosciuta... una bella porcheria. Ma, appunto, non credo proprio che sia così.

Semplicemente, chi ha scritto LMS non aveva pensato minimamente alla possibilità di utilizzare LMS per fare "DSP" o altre cose "strane", ma si è preoccupato solo di dare la possibilità di convertire le diverse possibili "sorgenti" da (quasi) qualsiasi formato a quei pochi formati supportati dalle prime "squeezebox" e purtroppo non è stato così lungimirante da prevedere la possibilità di sviluppi futuri diversi. D'altro canto, a chi pagava lo sviluppo interessava avere -e presto- qualcosa di funzionante per i propri prodotti, non certo progettare e realizzare una architettura "universale" che molto tempo dopo altri avrebbero sfruttato per scopi completamente diversi...

Sfortunatamente, mi pare che il modo in cui è stato organizzato quel programma mal si presta a fare ciò che vorremmo. Che lo si possa fare uscendo in flac è già di per sé niente altro che un caso fortuito.

Per i nostri fini (ed altro ancora) sarebbe necessario introdurre pesanti modifiche al codice. Ad esempio trasformando le "meta variabili" (%d, %D, ecc, ecc) in vere e proprie variabili, cui si possa anche assegnare un valore nel file di configurazione. Magari non sarebbe neanche troppo complicato da fare... (ammesso che gli sviluppatori accettino un simile cambiamento).

BTW: hai visto questi?

Synology Forum ? View topic - Transform LMS in simple DSP for Digital Room Correction

custom-convert.conf DOWNIX 6ch

[marcoc1712]

no. Anche se entrambi possono contenere un "payload" costituito da uno stream PCM, WAV ed AIFF sono due "container" sensibilmente diversi tra loro.

Si, ma per descriverli (e generarli) quello che cambia è 'solo' l'endian, per il resto sono uguali ( almeno ai ns. fini v. comandi flac).

cosa che sarebbe ovvia... non fosse che, se non ricordo male, mi pare avessimo stabilito che per LMS "pcm" non significa "PCM raw", ma è una sorta di "meta-formato" che può essere indifferentemente wav, aif o raw PCM.

Tu lo avevi stabilito, io non lo so, dalle mie prove pare sia così e tornerebbe con il fatto che fare stream di un wav sarebbe una violazione dello standard.

Comunque sia, non intendevo dire di uscire in aiff con una entry "wav pcm * *", ma piuttosto con una entry "wav aif * *".

Apparentemente, nel file di configurazione di default esiste già qualcosa del genere... solo che i comandi escono in raw PCM!!!

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

ogg aif * *
        [sox] -q -t ogg $FILE$ -t raw -r 44100 -c 2 -2 -s $-x$ -

mpc aif * *
        # IR
        [mppdec] --raw-be --silent --prev --gain 2 - -

(questa è una roba a dir poco imbarazzante... indecente... LMS mi piace sempre meno).

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'.

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.

Comunuqe, non l'ho scritto io...

Comunque (se non è stato già fatto) si può provare a vedere che succede se si esce in aiff in una entry di tipo "flc aif * *".

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

sì, quello l'avevo visto... (sono quelle che ho chiamato "meta-variabili"). Nulla di più di una sostituzione. Quella è una pratica furba, comoda e (relativamente) comune.

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,...).

Tornando al file di configurazione, alle "meta-variabili" (o comunque le si voglia chiamare) ed alle definizioni delle entries (#FT o quello che sia), ho notato che nel file di configurazione di default ci sono delle entries che fanno resampling, e queste usano una apposita "capability", "D", nonché una apposita coppia di meta-variabili: "%d" o "%D" e "RESAMPLE". Ad es.:

flc mp3 * *
        # FB:{BITRATE=--abr %B}T:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=--resample %D}
        [flac] -dcs $START$ $END$ -- $FILE$ | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

sfortunatamente il meccanismo sembra essere "monodirezionale", cioè pensato per il caso in cui è LMS stesso che "decide" quale debba essere il S/R di destinazione, sostituisce il relativo valore a "%d" o "%D" e quindi lo passa al comando esterno attraverso la sostituzione della variabile "$RESAMPLE$".

Se è così, c'è ben poco da fare. A meno che LMS non preveda anche la possibilità di mettere in "RESAMPLE" un valore arbitrario fisso (anziché usare "%d" o "%D"), ed in tal caso legga da lì il valore del S/R "di uscita" da comunicare al player.

Purtroppo però questo mi pare a dir poco improbabile: a quanto vedo, in "RESAMPLE" ci va una stringa con l'opzione specifica per il comando utilizzato e non (solo) il "target" S/R. Il che vorrebbe dire che per poter leggere da quella "variabile" il S/R desiderato, LMS dovrebbe interpretare correttamente una stringa sconosciuta... una bella porcheria. Ma, appunto, non credo proprio che sia così.

Infatti non è così, nel convert.conf attivi la richiesta (es , per il downsampling) e specifichi la sintassi con la quale il parametro (la meta variabile) viene passato al comando ({-r %d}), che ovviamente è specifico del bianario di conversione utilizzato.

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, o di partire da una data posizione o...

Semplicemente, chi ha scritto LMS non aveva pensato minimamente alla possibilità di utilizzare LMS per fare "DSP" o altre cose "strane", ma si è preoccupato solo di dare la possibilità di convertire le diverse possibili "sorgenti" da (quasi) qualsiasi formato a quei pochi formati supportati dalle prime "squeezebox" e purtroppo non è stato così lungimirante da prevedere la possibilità di sviluppi futuri diversi. D'altro canto, a chi pagava lo sviluppo interessava avere -e presto- qualcosa di funzionante per i propri prodotti, non certo progettare e realizzare una architettura "universale" che molto tempo dopo altri avrebbero sfruttato per scopi completamente diversi...


Sfortunatamente, mi pare che il modo in cui è stato organizzato quel programma mal si presta a fare ciò che vorremmo. Che lo si possa fare uscendo in flac è già di per sé niente altro che un caso fortuito.

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). Esistono già plugin che fanno DSP e DRC, quindi non è impossibile, è vero che quanto è stato ad oggi (ieri) realizzato è mirato a supportare l'hw specifico logitech... e vorrei vedere...

Per i nostri fini (ed altro ancora) sarebbe necessario introdurre pesanti modifiche al codice. Ad esempio trasformando le "meta variabili" (%d, %D, ecc, ecc) in vere e proprie variabili, cui si possa anche assegnare un valore nel file di configurazione. Magari non sarebbe neanche troppo complicato da fare... (ammesso che gli sviluppatori accettino un simile cambiamento).

Bisogna distinguere:

Introdurre un nuovo 'codec' (li chiamano così) come è stato fatto per il DSD è fattibilissimo, sostituirne uno esistente per fargli fare cose diverse è possibile, intervenire sul meccanismo vero e proprio la vedo dura, ma l'unico punto in cui sarebbe necessario sarebbe per rimuovere il vincolo di conversione WAV/PCM che tu mi hai spiegato essere imposto dallo standard.

Trasformare le 'metavariabili' è quello che intendevo fare io quando parlavo di un plugin per la gestione dei parametri di upsampling, sullo stile di quanto fatto per il DSD, ma avrei usato una nuova serie di variabili, utilizzate per generare i comandi da scrivere nel convert.conf.

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.

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).

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...

BTW: hai visto questi?

Synology Forum ? View topic - Transform LMS in simple DSP for Digital Room Correction

custom-convert.conf DOWNIX 6ch

No, ci butto un occhio.

[marcoc1712]

BTW: hai visto questi?

Synology Forum ? View topic - Transform LMS in simple DSP for Digital Room Correction

custom-convert.conf DOWNIX 6ch

Interesante.

Il primo esce con -t wav (che a me non funziona) ma non si vede l'intestazione del comando, originariamente era certamente un flc pcm * *. Non cambiando il s/r e nessun altro parametro del formato, funziona xchè il player a valle legge l'header dal file flac, se volesse fare anche upsampling, sarebbe costretto ad uscire in Flac...

Il secondo è probabilmente un buon esempio di script cui ti riferivi, vero?

[DacPassion]

Tutto questo mi inquieta non poco...
Attualmente ho risultati soddisfacenti, ma è un bene "abbracciare" questa soluzione che, forse, è troppo legata al passato?
Non ho capito bene cosa vogliono far fare da grande a LMS, si vuole continuare lo sviluppo per far funzionare i vari squeezebox che, fisiologicamente, andranno sempre a diminuire oppure si vogliono prendere strade diverse?
Nel secondo caso, quali strade? Un media server tutto fare o qualcosa di più (o almeno anche) HI-FI?
In ogni caso mi sembra che LMS abbia bisogno di una grande operazione di "svevcchiamento".

[antonellocaroli]

Tutto questo mi inquieta non poco...
Attualmente ho risultati soddisfacenti, ma è un bene "abbracciare" questa soluzione che, forse, è troppo legata al passato?
Non ho capito bene cosa vogliono far fare da grande a LMS, si vuole continuare lo sviluppo per far funzionare i vari squeezebox che, fisiologicamente, andranno sempre a diminuire oppure si vogliono prendere strade diverse?
Nel secondo caso, quali strade? Un media server tutto fare o qualcosa di più (o almeno anche) HI-FI?
In ogni caso mi sembra che LMS abbia bisogno di una grande operazione di "svevcchiamento".

Mah sinceramente a me va bene giá cosi com é....come funzionamento lo ritengo giá migliore di mpd con i vari client (chiaramente il mio é un caso dual pc)...

giá il fatto di avere diviso i compiti del server dal player puó essere un aspetto positivo importante....cosa che non é possibile con mpd....

Nel mio caso mi trovo alla grande!!! un pc che uso come player (sqeezelite, jplay e nad) e l´altro con LMS, Hqplayer e ultimamente sto provando anche Bug head Emperor che non é male....

[marcoc1712]

Tutto questo mi inquieta non poco...
Attualmente ho risultati soddisfacenti, ma è un bene "abbracciare" questa soluzione che, forse, è troppo legata al passato?
Non ho capito bene cosa vogliono far fare da grande a LMS, si vuole continuare lo sviluppo per far funzionare i vari squeezebox che, fisiologicamente, andranno sempre a diminuire oppure si vogliono prendere strade diverse?
Nel secondo caso, quali strade? Un media server tutto fare o qualcosa di più (o almeno anche) HI-FI?
In ogni caso mi sembra che LMS abbia bisogno di una grande operazione di "svevcchiamento".

LMS in versione 7.7.4 è l'ultima versione ufficialmente supportata da Logiteck, tra l'altro è l'unica che può 'legalmente' distribuire il firmware per i lettori Squeezebox 'veri'. Credo che Logiteck la supporterà certamente almeno fino alla scadenza dei tre anni dopo la vendita dell'ultimo SB fisico (2017), probabilmnete anche per un ragionevole periodo dopo questa data.

La versione 7.8, inizialmente rilasciata da Locitek e quindi 'disconosciuta', è stata adottata dalla community ed adesso (7.8.1) è la versione 'stable' pre chiunque voglia essere svincolato da Logitek, ma rinunciando alle evoluzioni della 7.9.

la versione 7.9 è la 'nuova' versione, gestita dalla community a partire dalla 7.8, creata circa un anno fa, purtorppo una serie di iniziative di 'rilancio' dell'ambiente SB sono naufragate per problemi legali, quindi si temeva un rapido collasso, ma così non è stato, anzi, grazie al geniale lavoro di triode con squeezelite (che non è scevro di difetti) LMS sta vivendo una nuova giovinezza e basta guardare il change log per capire quanto siano dinamici gli sviluppatori.

Non credo sarà mai un media server tutto fare (qualcuno lo usa veramente per i video o le immagini?) non capisco perchè lo definisci non hi-fi, cosa lo rende o meno tale? sono parzialmete daccordo con la necesità di 'svecchiamento', ma non credo che intendiamo la stessa cosa.

Certo, se il tuo scopo principale è l'upsampling ed il DSP, allora probabilmente ci sono prodotti più indicati, ma sei sicuro che riescano a farlo in PCM? Hanno le stesse funzionaità di gestione della libreria? Sono altrettanto versatili nel trattare sorgenti remote? ...

Prova a elencare i concorrenti (reali) di LMS e fai una tabella comparativa delle funzionalità, se ne trovi uno più versatile, per favore indicamelo.

Per il futuro... Fino a che Logiteck pagherà Michael per mantenere la 7.7.4, 'tollerando' che si dedichi nel contempo anche alla 7.8 ed alla 7.9, è facile prevedere che molte cose rimarranno in comune alle tre versioni (ed è un bene). Il supporto agli SB fisici è una GRANDE funzionalità, non immagini quanti ce ne siano ancora in giro, per fortuna, altrettanto dicasi per UPNP/DNLA.

Quello che io prevedo è una 'main stream' di sviluppo sulle funzionalità 'core' del server e - speriamo - dell'emulatore software (squeezelite), quindi una serie di progetti/distribuzioni 'stile' Vortexbox o Daphile che ne presentino le funzionalità in modo mirato a target diversi (audiofii, ascoltatori occasionali, soluzioni multiambiente,...). Spero solo ciò avvenga in modo 'ordinato' e nel rispetto delle regole e pratiche di buona cittadinanza, magari utilizzandp quanto già previsto o in caso contrario migliorandolo a beneficio di tutti.


p.s.


Se a inquietarti sono i 'coloriti' giudizi di Paolo sulle pratiche di sofwate engeenering ipoteticamente applicate in LMS, tranquillizzati:

a. Per quanto riguarda il codice sono solo ipotesi, ho personalmente verificato che non sono vere (come lo stesso Paolo presupponeva).

b. In giro, anche in prodotti commeriali dedicati a compiti ben più critici, c'è di peggio, dove non puoi accedere al codice... beh... chi può saperlo?

[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.