upsampling (universo LMS/Squeezelite/Squeezeplay)

[antonellocaroli]

Mi pare che anche Filippo(antonellocaroli) abbia riportato le mie stesse impressioni. Quindi siamo almeno in due. Non ho capito se Giorgio possa
esprimere un giudizio.

Si anche io ero giunto alle stesse....
ma siamo in pochi qua per giudicar...

[UnixMan]

Notizia positiva: per far si che LMS trasmetta le informazioni correttamente, basta fare qualche passo indietro e modificare i comandi conversione di custom-conver.conf come segue:

wav pcm * *
	# FT:{START=--skip=%t}U:{END=--until=%v}
	[flac] -cs  $START$ $END$ -- $FILE$ |[sox] -q -t flac - -t raw -r 192000 -c 2 -3 -s -L - gain -3 rate -v 192000

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

Notizia negativa: Squeezelite, nel caso di pcm, riverifica l'header del file originario , quindi prova ad aprire lo stream (192K/24) a 44.1/16, ovviamente con risultati disastrosi...

ecco, questo ha molto senso... e tende ad avvalorare la seconda ipotesi di cui sopra.

Francamente non ho capito perchè lo faccia con pcm e non con flac

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!

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

[DacPassion]

Mi pare che anche Filippo(antonellocaroli) abbia riportato le mie stesse impressioni. Quindi siamo almeno in due. Non ho capito se Giorgio possa
esprimere un giudizio.
In generale.

Giovanni, purtroppo ora sono "bloccato" ...di fare prove semiserie se ne riparla a fine maggio

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