upsampling (universo LMS/Squeezelite/Squeezeplay)

[marcoc1712]

Marco per fortuna il DSD non è una sponda che mi interessa. Per me solo PCM + DAC NOS R-2R. E' la mia "religione"
Non c'è spazio per il DSD. Sono pienamente soddisfatto del mio sistema e non vado a rincorrere altre strade....Hic et nunc solo PCM...postea semper PCM datur

Lo so, ...ti volevo soltanto punzecchiare...

[DacPassion]

bene la "flc flc" ma, queste due:

sono pura follia: prima converti da pcm a flac (comprimi) poi passi il tutto a sox che (internamente) deve riconvertire da flac a pcm (decomprimere), processare lo stream ed infine riconvertire da pcm a flac, cioè comprimerlo di nuovo!

Se avete usato qualcosa del genere lo credo bene che l'occupazione di CPU è enormemente più alta di quella di Squeezelite quando è lui a fare resampling!

Ma alla fine avendo una libreria di soli flac uso solo flc flc giusto?
Le altre due come andrebbero modificate?

si può fare, ma di certo non direttamente con una di quelle righe. È necessario scriversi uno script che riconosca il formato dei dati in ingresso ed applichi comandi diversi a seconda del s/r.

Dopo di che, anziché usare direttamente flac, sox, ecc., nel file di configurazione di LMS si usa quello script (che fa tutto lui).

Ovviamente fermo restando che "l'uscita" verso i player deve sempre essere necessariamente flac e non altro ("flc flc", "aif flc", "wav flc", ecc).

La cosa per altro ha anche altri vantaggi: si semplifica notevolmente la configurazione di LMS, e si ha un solo punto da modificare se ad es. si vogliono cambiare i parametri di resampling, ecc.

Quindi squeezelite lo fa non perché è possibile farlo con sox ma perché è squeezelite a gestire la cosa?

[antonellocaroli]

Ma alla fine avendo una libreria di soli flac uso solo flc flc giusto?
Le altre due come andrebbero modificate?
Quindi squeezelite lo fa non perché è possibile farlo con sox ma perché è squeezelite a gestire la cosa?

1) Se hai una libreria solo di flac...basta flc flc
2) non é proprio corretto...in sqeezelite come in LMS imposti tu il rate (176400), con -u vLE..... -r 176400 (non vorrei sbagliarmi ma nei comandi sqeezelite non é specificato da nessuna parte un comando sincrono...ma solo asincrono X al posto di E dove E indica "exception - avoids resampling if the output device supports the playback sample rate natively."

-R -u [params]        Resample, params = <recipe>:<flags>:<attenuation>:<precision>:<passband_end>:<stopband_start>:<phase_response>,
                         recipe = (v|h|m|l|q)(L|I|M)(s) [E|X], E = exception - resample only if native rate not supported, X = async - resample to max rate for device, otherwise to max sync rate
                         flags = num in hex,
                         attenuation = attenuation in dB to apply (default is -1db if not explicitly set),
                         precision = number of bits precision (NB. HQ = 20. VHQ = 28),
                         passband_end = number in percent (0dB pt. bandwidth to preserve. nyquist = 100%),
                         stopband_start = number in percent (Aliasing/imaging control. > passband_end),
                         phase_response = 0-100 (0 = minimum / 50 = linear / 100 = maximum)

Io ancora non ho capito quel flags = num in hex

Anzi rileggendo bene anche questo dovrebbe essere sincro -u vLX.... -r 176400

Provo a fare una traduzione di questo:
[sox] -q -t wav - -t flac -C 0 -b 32 - gain -3 rate -v -L -a -b 90.7 176400 dither -S

-u vLX::-3:32:90.7 -r 176400
o
-u vLX::-3:32:90.7 -r 176400-176400


qualcuno mi corregga...

[marcoc1712]

Ouch, sono rimasto indietrissimo...

Probabilmente continuiamo a non capirci e quasi certamente è a colpa del modo dispersivo provocato dal quotare i singoli punti, provo a riassumere in modo 'organico' la situazione una volta ancora, poi è lo stesso.

1. la conversione a qualsiasi formato pcm raw da LMS usando FLAC.exe funziona, come ho scritto, solo per i formati = 44.1K/16.

2. Usando sox -t wav... funziona solo per i formati = 44.1K/16.

3. Il play di un file WAV convertito e/o nativamente > 44.100/16 (es 192000/24) funzione certamente da mac, Filippo riporta anche da Linux e da Win64, da win32 no, comportandosi ESATTAMENTE come per il caso 2.

Ora, io sono una capra, ma visto che quello che gira tra LMS e Squeezelite è SEMPRE uno stream e non un file, è evidente che LMS ha un modo per informare Squeezelite del formato dello stream, se non ci fosse modo, nessun file WAV o AIFF <> 44100/16 verrebbe correttamente eseguito, sbaglio? se si, dove?

Tu sostieni che LMS 'mantiene' SEMPRE i dati del file in ingresso in caso di conversione x-> pcm, quindi in nessun caso il resampling può funzionare, mentre la conversione a parità di encoding, endian e bitrate si.

Per supportare la tua tesi, bisogna però che:

a. LMS su Win32 sia diverso e 'bacato' e non riesca a rilevare correttamente i parametri dal file in ingresso.
b. Io mi sia sbagliato e su mac non funzioni l'upsampling da sox in fase di conversione.

a. è molto strano, b è possibile, anzi probabile, ma da verificare.

Io dico solo che è almeno altrettanto probabile che il protocollo di comunicazione tra Lms ed i lettori (tra cui squeezelite) preveda informazioni in merito al formato dello stream (privo di header, per sua natura), di conseguenza lms gestisca delle variabili in cui viene 'registrato' il valore da passare.

Il 'modo' con cui queste variabili vengono alimentate è probabilmente guidato dalla valorizzazione opportuna dei parametri 'tipo' %d, D, B,... nella prima riga dei comandi di conversione, presumibilmente con default dal file di origine, ma non escludendo a priori altri metodi.

Di fatto -r 192000 -b 24 -c 2 -L -s -t raw -... servono proprio ad informare il programma che riceve lo stream raw in output (-) che questo è a 192000 Hz, 24 bit, sinbed-integer, 2 canali e little endian, è il modo 'raccomandato' da SOX in caso di raw.

Certamente non è detto che LMS li usi, ma il modo per farlo - almeno con sox - c'è, non è 'impossibile'.

Tra l'altro lo ammetti anche tu appena dopo, scrivendo che potrebbe essere la soluzione del problema, quindi non è impossible, capisco io.

Poi ripeto, è probabile che mi sia sbagliato io, ma per favore spiegami da dove nasce l'impossibilità.

In merio ai file .conf, nella mia esperienza e nelle indicazione che trovi sul forum la pratica cosnigliate è un'altra e corrisponde a quella che ho descritto, se non altro perchè è più chiara e mette al riparo da variazioni 'sibilline' in caso di cambio di versione.

Molti dei problemi che ho riscontrato nelle configurazioni qui postate e non funzionati, spesso sibiillinamente illudendo del contrario, erano dovute ad 'interferenze' tra i due files.

In merito alle due 'folli' conversioni a flac, è quello che fa LMS nello standard, al netto dell'upsamling, ovunque intervenga una trascodifica: prima converte, poi applica le altre trasformazioni. A mio avviso è legato sempre al dicorso del glitch nel gapless e della possibilità di muoversi velocemente nel file.

L'occupazione è molto più alta a prescindere, anche usando solo sox da flac a flac, in particolare su mac.

Interessante il discorso dello script, riesci a postarne un esempio da provare?

[marcoc1712]

Quindi squeezelite lo fa non perché è possibile farlo con sox ma perché è squeezelite a gestire la cosa?

Corretto, con SOX è possibilisimo farlo ma in CONVERT.conf non puoi mettere due righe

flc flc * *

con impostazioni diverse.

Se funzionerà lo script di Paolo, potrai usarlo con una sola riga, qindi il limite decadrà. Come vedi bisogna stare attenti a 'dare colpe' quando sono coinvolti diversi componenti software 'loose integrated'.

Squeezelite prevede l'opzione e quindi la gestisce.

[antonellocaroli]

Marco penso che sul custom-convert.conf e convert.conf Paolo abbia ragione.
Se LMS rileva una riga in Custom non va a leggere la stessa in convert....sperimentato nelle prove fatte fino adesso...

[marcoc1712]

2) non é proprio corretto...in sqeezelite come in LMS imposti tu il rate (176400), con -u vLE..... -r 176400 (non vorrei sbagliarmi ma nei comandi sqeezelite non é specificato da nessuna parte un comando sincrono...ma solo asincrono X al posto di E dove E indica "exception - avoids resampling if the output device supports the playback sample rate natively."

E la differenza dov'è? Se metti E e tra i rate disponibili c'è quello sincrono lo usa.

Però occhio: Il significato di -r in SOX è quello di fare upsampling a quella frequenza ( o meglio, indica che il file in uscita è a quella frequenza, con rate potresti in teoria cambiarlo di nuovo, come giustamente ha sottolineato Paolo) in squeezelite indica le frequenza ammese dal lettore, anche indipendentemente dal resample, sia con X che con E il resample avverrà SMEPRE alla massima frequenza ammessa, in un caso (E) prima cercando tra le sincrone, ma se non ne trova va comunque...

[antonellocaroli]

Corretto, con SOX è possibilisimo farlo ma in CONVERT.conf non puoi mettere due righe

flc flc * *

con impostazioni diverse.

Se funzionerà lo script di Paolo, potrai usarlo con una sola riga, qindi il limite decadrà. Come vedi bisogna stare attenti a 'dare colpe' quando sono coinvolti diversi componenti software 'loose integrated'.

Squeezelite prevede l'opzione e quindi la gestisce.

Non sono daccordo...quale sarebbe l´opzione? hai letto il mio post precedente Marco?

[antonellocaroli]

E la differenza dov'è? Se metti E e tra i rate disponibili c'è quello sincrono lo usa.

Appunto...non esiste una opzione in sqeezelite...si tratta solo di fissare un rate x4 176400 lo stesso che si fa in flc flc

Tra queste due non c´é differenza:
[sox] -q -t wav - -t flac -C 0 -b 32 - gain -3 rate -v -L -a -b 90.7 176400 dither -S

-u vLX::-3:32:90.7 -r 176400 (se non ho sbagliato la sintassi)

sono tutte e due sincro....
perché ci vorrebbero due flc flc?

solo in caso il file in ingresso non é 44100 (ma in quel caso anche in sqeezelite bisogna cambiare non c´é un opzione che lo fa in auto)

[antonellocaroli]

E la differenza dov'è? Se metti E e tra i rate disponibili c'è quello sincrono lo usa.

Marco se metti E e non imbrogli sqeezelite dicendo che l´uscita é solo a 176400 con -r 176400 o -r 176400-176400 (non ricordo) non fa nessun resample ma esce a 44100