infatti, ti avevo detto di togliere la X, se fai così funziona.Quote:
Originariamente inviato da DacPassion
Printable View
infatti, ti avevo detto di togliere la X, se fai così funziona.Quote:
Originariamente inviato da DacPassion
Perdurando il maltempo, ho iniziato l alettura del codice, per il momento di LMS a seguire anche di squeezelite, per capire meglio cosa fanno.
Sono all'inizio, ma già alcune cose sono chiare:
Il passaggio per FLAC $START $END è indispensabile soprattutto per l'utilizzo di file multitraccia, che altimenti non potrebbero venire spezzati dai cue sheet, oltre al discorso dell'aggiustamento di fino per evitare il glith nel gapless.
I formati gestiti tramite conversione ( X Y * * != -) non vengono trattati direttamente da LMS, che li delega ad un eseguibile specifcio per ogni sisema operativo. In Win32 (sul mio pc) produce un errore, questo probabilmente è il motivo del mancato funzionamento.
WAV e AIFF vengono gestiti entrambi come PCM, ma non esattamente allo stesso modo DOPO l'esecuzione dell'eseguibile di cui sopra, al momento sono arrivato qui, ma se continua a piovere ne sapremo di più presto.
Ciao
Dinque sto utilizzando con soddisfazione Lms su un pc win collegato in streaming a daphile su altro pc dove risiede anche il dac.
Ho settato lms con flc flc disabilitato , quindi a daphile arriva uno stream pcm, almeno spero, da qualche parte avevo letto che squeezelite riconvertirebbe tutto di nuovo in flac e poi in pcm..... penso e spero sia una boiata, chiedo hai piu esperti.
Grazie
Inviato dal mio LG-D855 utilizzando Tapatalk
Ciao,Quote:
Originariamente inviato da keres
A me non risulta e non ne capirei nemmeno la necessità, ma mi serve qualche altro we di pioggia per averne la certezza:blblbl
Vi è capitato di imbattervi in qualche plug-in per LMS che gestisce il wake on lan (di un eventuale render)?
Se Intendi per Squeeezelite, No.Quote:
Originariamente inviato da DacPassion
Esiste però la possibilità di inibire lo sleep del server.
https://up.nexthardware.com/user_ima...1 19:10:12.png
Boh ragazzi. io sto andando cosi : mi sono accattato un PC con processore di un certo livello(Core duo quad Q9500 bello tosto):
Resampling su LMS, con Mint, spinto fino 352800 Khz....sull'altro miniPC ( Futro ) Voyage con Squeezelite che non fa' nientaltro
che passare lo stream al DAC. Le prove comparative con Squeezelite deputato al resampling orientano decisamente l'ago della
fatidica bilancia assolutamente verso la soluzione del resampling su LMS....un risultato all'ascolto davvero magnifico.
L'impegno della rocciosa CPU Intel(4 core) è quantificabile in una media del 25-30%. La rete viaggia nell'ordine dei 350 K in media.
Insomma l'impegno hardware c'è ma il risultato è proprio di elevatissimo livello....non si torna indietro....almeno ad ora.
Nell'immagine si vede la finestra di Putty che mostra cosa elabora ALSA in Voyage.
Abbiamo constatato con Giovanni che per fare resample con sqeezelite/libsoxr con voyage bisogna installare le libsoxr...
dopo essersi assicurato che il tutto ci sia
apt-get install build-essential libasound2-dev libflac-dev libmad0-dev libvorbis-dev libvo-aacenc-dev libfaad-dev libmpg123-dev
mkdir sox
cd sox
wget XXXX://ftp.us.debian.org/debian/pool/main/libs/libsoxr/libsoxr-dev_0.1.1-1_i386.deb <-----non so se necessario cmnq
wget XXXX://ftp.us.debian.org/debian/pool/main/libs/libsoxr/libsoxr-lsr0_0.1.1-1_i386.deb
wget XXXX://ftp.us.debian.org/debian/pool/main/libs/libsoxr/libsoxr0_0.1.1-1_i386.deb
dpkg -i *.deb
Al posto di XXXX http
Fatto!!!
A rilento (c'è il sole ed il beach tennis chiama...) continuo con le mie indagini e, purtroppo, ho già trovato più di un punto in cui l'upsampling da wav 'inciampa' in piccole ma fastidiose scorciatoie.
E' evidente che LMS non è stato pensato per fare upsamplig, ma piuttosto per fare eventualmente downsampling e limitare il bitrate in fase di trasmissione, d'altronde è figlio del suo tempo.
Comunque, con poche modifiche (a puro scopo di test) sono riuscito a 'far veder' a squeezelite lo stream al samplerate corretto, ma continuo ad adottenere 'rumore bianco' quindi qualche altro parametro non viene interpretato correttamente, in particolare mi lascia perplesso il fatto che squeezelite riconosca lo stream in ingresso come audio-L16 e non pcm, può essere un semplice effetto estetico, ma le coincidenze...
Come prossimo passo mi scaricherò il sorgente di Squeezelite e proverò a verificare cosa si aspetta di diverso rispeto a quello che ottiene, anche se ai fini pratici, non credo sia ipotizzabile a breve una soluzione diversa di quella individuata passando da flac per l'upsampling. Le modifiche che ho individuato le ho segnalate, ma capisco che lo sforzo per verificarne il corretto funzionamento in ogni possibile situazione è grande e non credo sia prioritario.
Ottimo, l'unico dato che mi lascia perplesso è la rete a 350 K(?): il bitrate per 352800/24 non compresso è 16934.40 Kbps CBR, compresso può scendere fino a 1411.20 Kbps (12x).Quote:
Originariamente inviato da bigtube
Ciao.
[/IMG][IMG]https://up.nexthardware.com/user_ima...2 20:59:16.pngQuote:
Originariamente inviato da marcoc1712
Questo è il monitor di sistema Marco. Giudica tu se ho mal interpretato....puo' essere
Mi pare si tratti di KB/s cioè KiloBytes = c.a. 2800 Kbit/sec, sempre non altissimo ma già più coerente con una compressione 5x.Quote:
Originariamente inviato da bigtube
Un richiamo ben piu' interessante dopo un inverno sotto la pioggia!!! Te credo.....comunque qui continuiamo ad apprezzare il tuo sforzo stanne certo.....ma questi sorgenti non si potrebbero ricompilare????Quote:
Originariamente inviato da marcoc1712
L'ho detta grossa eh.....
OH Perbacco!!! Piu' che giusto.....non mi bacchetti prof.:lokaroQuote:
Originariamente inviato da marcoc1712
considerando l'overhead, direi che siamo piuttosto intorno ai 3.2Mbit/s... ;)Quote:
Originariamente inviato da marcoc1712
.Quote:
Originariamente inviato da bigtube
No, non l'hai detta grossa, a parte che - tecnicamente - il perl non è compilato ma interpretato, è certamente possibile ricostruire la distribuzione per i diversi ambienti e metterla in 'ordine di marcia' (capisco che intendevi dire questo) ma:
a. è complicato e time consuming.
b. diventeresti 'dipendente' dalla mia capacità/volontà/disponibilità per ottenere gli aggioramenti.
c. diventerei di fatto il mantainer di una versione alternativa, cosa che vorrei evitare e che se dovessi mai arrivare a fare cercherei di progettare edorganizzare al meglio, altrimenti diventa un impegno insostenibile (...sia mai che me ne vada a fare un viaggio in Tibet...).
Visto che comunque (almeno al momento) le modifiche che ho provato non sono risolutive, lo sconsiglio in assoluto, ma se proprio proprio vuoi provarle, allora puoi clonarti in locale il mio repository (che è disponibile in github) ed eseguire LMS da sorgente, avendo cura di selezionare di volta in volta il branch standard o quello di test.
Sembra più difficile di quello che in realtà è, ma ripeto che al momento a mio avviso non ne vale la pena, dovessi individuare la soluzione 'definitiva' (o almeno completamente funzionante) allora forse...
p.s.
Sotto la pioggia? Ma tu non vivi in quel fantastico pezzo di paradiso dove le precipitazioni si misurano in micron?
Marco guarda..... faccio prima a seguire il tuo consiglio....lassamo perde....sto benissimo cosiQuote:
Originariamente inviato da marcoc1712
Anche in paradiso piove...zzo se piove....dove sto io (in pratica in campagna) a qualcuno l'alluvione gli ha devastato tutto e anch'io ho avuto qualche danno (tanta fortuna).
Per non dire di quello che è successo a Olbia...you remember....una catastrofe quasi biblica...poveretti....e povere le vittime che hanno perso la vita....mica poco
Hai ragione, è stata una vera catastrofe.Quote:
Originariamente inviato da bigtube
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:Quote:
Originariamente inviato da marcoc1712
Che è quello che stavo sperimentando su mac prima dell'intervento di Paolo, che ha evidenziato quelli che lui ha definito 'errori' nel comando SOX - probabilmente con buona ragione - ma sta di fatto che così LMS esce con uno stream corredato delle corrette informazioni, quindi lascio ad altri l'ottimizzazione del comando, ma questa è (sarebbe) la strada da percorrere.codice: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
NOTA BENE: -t raw è essenziale, -t wav non funziona.
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...
Francamente non ho capito perchè lo faccia con pcm e non con flac, forse qualcuno più esperto di me (Paolo) può spiegarcene le motivazioni sottostanti, ma stanti così le cose non c'è verso. Proverò a segnalare la cosa, ma ho poche speranze...
CONCLUSIONI: Se volete fare upsampling in LMS dovete necessariamente passare da FLAC (o presumibilmente altri formati lossless diversi da PCM).
Giovanni riporta che questa configurazione ha vantaggi qualitativi rispetto all'upsampling su Squeezelite, quindi giudicate voi.
Sarebbe interessante sperimentare (ad esempio su daphile, ma va bene qualsiasi LMS + Localplayer plugin) se le differenze sonore tra l'upsampling eseguito da LMS o da Squeezelite sussistono anche in configurazione 'local player' (cioè sulla stessa macchina).
Mi pare che anche Filippo(antonellocaroli) abbia riportato le mie stesse impressioni. Quindi siamo almeno in due. Non ho capito se Giorgio possaQuote:
Originariamente inviato da marcoc1712
esprimere un giudizio.
In generale se qualcuno vuole fare l'esperienza puo' usare Daphile sul PC headless in pratica con risultati omogenei rispetto a cio' che ho fatto io
L'unica variante è che io uso un sistema tutto Linux.....del quale sono veramente soddisfatto . Tuttavia non credo che con Windows ci siano differenze
significative, rimanendo coi piedi per terra. Non sarebbe male se anche altri sperimentassero.....io lo consiglierei fortemente visti o sentiti i risultati.
Si anche io ero giunto alle stesse....Quote:
Originariamente inviato da bigtube
ma siamo in pochi qua per giudicar...
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.Quote:
Originariamente inviato da marcoc1712
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).
ecco, questo ha molto senso... e tende ad avvalorare la seconda ipotesi di cui sopra.Quote:
Originariamente inviato da marcoc1712
Azz, Marco, ma è OVVIO!Quote:
Originariamente inviato da marcoc1712
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!
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.Quote:
Originariamente inviato da UnixMan
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.
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.Quote:
Originariamente inviato da UnixMan
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.
Giovanni, purtroppo ora sono "bloccato" ...di fare prove semiserie se ne riparla a fine maggio ;-)Quote:
Originariamente inviato da bigtube
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".Quote:
Originariamente inviato da marcoc1712
questo invece è da chiarire, perché quello che dici qui sopra mi pare piuttosto contraddittorio. Le possibilità sono due:Quote:
Originariamente inviato da marcoc1712
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.
anche questo è abbastanza ovvio!Quote:
Originariamente inviato da marcoc1712
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 ]
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.Quote:
Originariamente inviato da marcoc1712
bella domanda. In effetti, parrebbe la cosa più semplice e sensata da fare. Non ho idea del perché si comporti diversamente.Quote:
Originariamente inviato da marcoc1712
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?
BINGO, questo è quello che non spiegavo e mi hai dato la spiegazione,Quote:
Originariamente inviato da UnixMan
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.Quote:
Originariamente inviato da UnixMan
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.
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).Quote:
Originariamente inviato da UnixMan
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).
no. Anche se entrambi possono contenere un "payload" costituito da uno stream PCM, WAV ed AIFF sono due "container" sensibilmente diversi tra loro.Quote:
Originariamente inviato da marcoc1712
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. :mmmmQuote:
Originariamente inviato da marcoc1712
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!!! :oooo ;blink1
(questa è una roba a dir poco imbarazzante... indecente... LMS mi piace sempre meno).codice: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 - -
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 * *".
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.Quote:
Originariamente inviato da marcoc1712
sì, questo è chiaro.Quote:
Originariamente inviato da marcoc1712
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-)Quote:
Originariamente inviato da marcoc1712
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.:
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$".codice: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$ - -
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
Quote:
Originariamente inviato da UnixMan
Si, ma per descriverli (e generarli) quello che cambia è 'solo' l'endian, per il resto sono uguali ( almeno ai ns. fini v. comandi flac).
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.Quote:
Originariamente inviato da UnixMan
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'.Quote:
Originariamente inviato da UnixMan
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...
Non va, perchè squeezelite usa lo stesso modulo per raw pcm e aif...Quote:
Originariamente inviato da UnixMan
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,...).Quote:
Originariamente inviato da UnixMan
Infatti non è così, nel convert.conf attivi la richiesta (es :D, 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.Quote:
Originariamente inviato da UnixMan
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...
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...Quote:
Originariamente inviato da UnixMan
Bisogna distinguere:Quote:
Originariamente inviato da UnixMan
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...
No, ci butto un occhio.Quote:
Originariamente inviato da UnixMan
Interesante.Quote:
Originariamente inviato da UnixMan
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?
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)...Quote:
Originariamente inviato da DacPassion
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....
Te credo Filippo....hai tutte le fuoriserie in garage....e su MPD purtroppo la penso ugualeQuote:
Originariamente inviato da antonellocaroli
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.Quote:
Originariamente inviato da DacPassion
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?
Ad onor del vero è possibile, certo non è semplice e quando ci ho provato non ci sono riuscito, ma l'installazione 'satellite' serve proprio a quello.Quote:
Originariamente inviato da antonellocaroli
Non chiedetemi poi come gestsce l'upsampling ecc, ecc... non ci sono arrivato.
Hai provato squeezelite che esce su Jplay? Cosa ne pensi? (io provai a Natale 2013, in qualche post ci sono i risultati).Quote:
Originariamente inviato da antonellocaroli
Confronto HQPlayer + NAA vs LMS + Squeezelite stessi files e stessi upsampling? (non ho dubbi sul nativo).
EDIT: Hai un link a qualcosa di leggibile in qualsiasi linguaggio 'umano' in merito a Bug head Emperor?
grazie.
Marco non solo l ho provato ma io lo uso con jplay, poi adesso funziona anche in ibernate..quindi...Quote:
Originariamente inviato da marcoc1712
I tuoi risultati quali erano???
il confronto con Hqplayer? a paritá di up se la giocano...non ci sono differenze eclatanti...ma preferisco Hqplayer in conversione PCM>DSD, anche se molti ritengono che la conversione pcm>dsd sia un degradare il suono , anche lo stesso autore di Bug head Emperor lo sostiene.
Bug head Emperor mi ha veramente stupito, al primo ascolto mi ha un po ricordato il cmp, ma é veramente avido di risorse se lo si spingi...ha un casino di opzioni/filtri
quando lo installi c´é il manuale in parte tradotto in inglese...poi c é un forum russo dove ne parlano tanto...ma ha piú di 200 pg e non ho avuto ne il tempo e ne la voglia di leggerlo (tradotto da G)
Bug Head Emperor player - ???????? 208 - ???????? ?? ????????? ???? - forum.doctorhead.ru - ????? ?? ?????????.
Ribadisco che in questo momento sono pienamente soddisfatto dei risultati, quello che mi preoccupa è il fatto che, mi sembra, LMS sia troppo legata al passato, nel senso che si percepisce (come spesso hai fatto notare tu stesso) che molte delle scelte fatte in LMS dipendono dai limiti delle reti e delle potenze di calcolo con i quali ci si doveva imbattere.Quote:
Originariamente inviato da marcoc1712
Ah, avevo frainteso, pensavo dicessi troppo legato al passato logitek, scusa.Quote:
Originariamente inviato da DacPassion
Si, in questo senso è evidente che porta nel suo dna la grande attenzione ai carichi, ma non è necessariamente un male, anzi, questo gli consente di operare su hw veramente minimo con ottime prestazioni.
Diventa un limite se lo si vuole utilizzare oltre gli scopi per cui è stato pensato SENZA realizzare il codice opportuno (come è stato fatto per il DSD), come abbiamo visto in molti casi funziona (FLAC) in altri no (PCM) ma, come ha spiegato Paolo meglio di me, era abbastanza prevedibile, la colpa dell'incaponimento (e della conseguente confusione) è in gran parte mia, chiedo venia.
Grazie per i link, approfondirò. Ma sei riuscito a fare conversione PCM -> DSD con LMS/squeezelite? Sempre con il convert.conf?Quote:
Originariamente inviato da antonellocaroli
Alla fine non ho comprato Jplay, non mi ha convinto. A mio avviso caratterizza molto il suono, che diventa 'pacione' tipo JRiver, se non un pizzico di più, un effetto loudness/eufonico piacevole su alcuni brani ma - a mio avviso - meno in altri. Stiamo ovviamente parlando di impressioni e gusti personali.
Non nascondo che la disputa con JRiver ha alzato un warning ed ha avuto un suo peso nella mia decisione.
Ho trovato qualcosa su CA e da quello che leggo applica dsp alla grande (molti lo usano off line per 'correggere' o 'rigenerare' i files, che è un concetto che personalmente rifuggo, se non fatto in funzione di precise caratteristiche di ascolto, i.e. DRC).Quote:
Originariamente inviato da antonellocaroli
Non dubito posso suonare piacevolmente, ma se apriamo quella porta le opzioni sono relamente tante. Leggerò meglio.