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. :-)
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):
Ora, ci sono due possibilità:codice:flc aif * * # FT:{START=--skip=%t}U:{END=--until=%v} [flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$
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!
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?
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...
quelle se non erro le chiama "capabilities"... ed ovviamente non era ciò a cui mi riferivo.
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.
quello forse è possibile
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).
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...
...e bisogna tenere conto anche dei vecchi player "hardware", le cui "specifiche" non possono essere cambiate.
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 * *").
fin tanto che fa quel che ti serve (a partire dal suonare bene), non vedo perché no.
che differenza c'è (ci dovrebbe essere?) tra un "media server tutto fare" e "qualcosa di più HiFi"?
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.
Rispondi quotando
