DSD in LMS con SOX

[antonellocaroli]

PS: ho provato a scaricare sox da mansr....ma questa non c´é verso di compilarla....

[marcoc1712]

si giusto!!! corretto e va!!!



nono é la versione non XP...
si potrebbe provare a fare il debug dell´errore

Si, si potrebbe provare, mi mandi l'ID?

[marcoc1712]

PS: ho provato a scaricare sox da mansr....ma questa non c´é verso di compilarla....

COme avevo scritto...


mantiene un branch separato (msvc) che però non ha allineato alle enuove modifche... quindi ho dovuto farlo nel mio repo, devi scaricare da li, branch: withDaphilePatches .

[antonellocaroli]

COme avevo scritto...


mantiene un branch separato (msvc) che però non ha allineato alle enuove modifche... quindi ho dovuto farlo nel mio repo, devi scaricare da li, branch: withDaphilePatches .

hai l´ ID

[UnixMan]

OK, ma a me serve sapere quali sono le righe di comando da produrre (anche indipendentemente da lms) per i casi che citavo, cioè:

[...] (DSD->PCM e DSD->DSD)

In modo da capire come 'giostrare' i parametri e produrre i comandi.

Ah, OK.

Allora, cominciamo con chiarire un punto "teorico": internamente sox "conosce" solo il PCM e lavora esclusivamente con quello (per altro, il DSD è pressoché impossibile da elaborare come tale a prescindere). Perciò, qualsiasi elaborazione fatta con sox passa (deve passare) per PCM (unica eccezione è una eventuale conversione di formato "bit perfect", da dff a dsf o viceversa).

Di conseguenza il workflow non può che essere qualcosa del genere:

DSD in -> (conversione a PCM) -> [elaborazioni varie] -> PCM out
DSD in -> (conversione a PCM) -> [elaborazioni varie] -> (conversione a DSD) -> DSD out

Se non vado errato, attualmente con sox non c'è che un unico modo per effettuare il primo passaggio: banalmente il filtraggio passa-basso. Cioè la stessa cosa che fanno i (no)DAC DSD nel dominio analogico, ottenendo un segnale analogico. Facendolo in digitale (PCM), il risultato è uno stream PCM.

(uno dei punti che dovremo chiarire - e/o lasciare come ulteriore opzione - è se in ingresso, prima di dare tutto in pasto a sox, non convenga piuttosto utilizzare qualcosa tipo dsd2pcm. O magari integrare anche quest'ultima lib in un nuovo "effetto" di sox -> Måns).

Andiamo al sodo. Indico tra "[]" gli elementi opzionali, tra "<>" quelli obbligatori e con un "$" i token/variabili da sostituire con i valori del caso. Come sappiamo, la riga di comando di sox è strutturata così:

sox [gen. opts] [input format spec] $INPUT [output format spec] $OUTPUT [processing chain]

Per brevità e semplicità, visto che il resto non cambia, di seguito mi limito a specificare solo l'ultima parte (processing chain), in forma "simbolica", cominciando con i due casi che conosciamo già:

1) PCM->PCM:

 [gain reduction] [pre-res-effects] [resampling] [post-res-effects] [dithering]

2) PCM->DSD:

 [gain reduction] [pre-res-effects] <resampling> [post-res-effects] <sdm>

3) DSD->DSD:

<lowpass filter> [gain reduction] [pre-res-effects] [resampling] [post-res-effects] <sdm> 

4) DSD->PCM:

 <lowpass filter> [gain reduction] [pre-res-effects] <resampling> [post-res-effects] [dithering]

Come è evidente, i primi due due casi (ingresso PCM) sono pressoché identici, salvo due differenze: la sostituzione del dithering (opzionale) con "sdm" (obbligatorio per l'uscita DSD) ed il resampling, che ovviamente per il DSD è necessario per raggiungere il s/r di uscita (mentre per il pcm serve solo nel caso si desideri un s/r di uscita diverso da quello di ingresso).

Idem per gli altri due casi (ingresso DSD), identici ai primi due salvo l'aggiunga del filtro passa-basso (obbligatorio) in ingresso (conversione dsd2pcm), prima di qualsiasi altra elaborazione (incluso "gain -h"):

Qui un esempio:

$ AUDIODEV=hw:0,0 /opt/sox-dsd/bin/sox -S -V3 pippo.dsf -b 32 -t alsa lowpass -2 22k gain -h rate -vMn $[ 4 * 48000 ] dither -s -p 24

/opt/sox-dsd/bin/sox:      SoX v14.4.2

Input File     : 'pippo.dsf'
Channels       : 2
Sample Rate    : 5.6448e+06
Precision      : 1-bit
Duration       : 00:04:24.63 = 1493764608 samples ~ 19847 CDDA sectors
File Size      : 373M
Bit Rate       : 11.3M
Sample Encoding: 1-bit Direct Stream Digital
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no


Output File    : 'hw:0,0' (alsa)
Channels       : 2
Sample Rate    : 192000
Precision      : 32-bit
Duration       : 00:04:24.63 = 50808320 samples ~ 19847 CDDA sectors
Sample Encoding: 32-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

/opt/sox-dsd/bin/sox WARN dither: no `shibata' filter is available for rate 192000; using sloped TPDF
/opt/sox-dsd/bin/sox INFO sox: effects chain: input      5.6448e+06Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: lowpass    5.6448e+06Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: gain       5.6448e+06Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: rate        192000Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: dither      192000Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: output      192000Hz  2 channels
In:100%  00:04:24.63 [00:00:00.00] Out:50.8M [      |      ]        Clip:0
Done.

e stessi casi di cui sopra, ma con DFF invece di DSF, se c'è differenza.

salvo ciò che metti dopo "-t" nelle definizioni del formato di in e/o out non dovrebbe cambiare nulla, come al solito.

[marcoc1712]

Ah, OK.

Allora, cominciamo con chiarire un punto "teorico": internamente sox "conosce" solo il PCM e lavora esclusivamente con quello (per altro, il DSD è pressoché impossibile da elaborare come tale a prescindere). Perciò, qualsiasi elaborazione fatta con sox passa (deve passare) per PCM (unica eccezione è una eventuale conversione di formato "bit perfect", da dff a dsf o viceversa).

Di conseguenza il workflow non può che essere qualcosa del genere:

DSD in -> (conversione a PCM) -> [elaborazioni varie] -> PCM out
DSD in -> (conversione a PCM) -> [elaborazioni varie] -> (conversione a DSD) -> DSD out

Se non vado errato, attualmente con sox non c'è che un unico modo per effettuare il primo passaggio: banalmente il filtraggio passa-basso. Cioè la stessa cosa che fanno i (no)DAC DSD nel dominio analogico, ottenendo un segnale analogico. Facendolo in digitale (PCM), il risultato è uno stream PCM.

(uno dei punti che dovremo chiarire - e/o lasciare come ulteriore opzione - è se in ingresso, prima di dare tutto in pasto a sox, non convenga piuttosto utilizzare qualcosa tipo dsd2pcm. O magari integrare anche quest'ultima lib in un nuovo "effetto" di sox -> Måns).

Andiamo al sodo. Indico tra "[]" gli elementi opzionali, tra "<>" quelli obbligatori e con un "$" i token/variabili da sostituire con i valori del caso. Come sappiamo, la riga di comando di sox è strutturata così:

sox [gen. opts]  [input format spec] $INPUT  [output format spec] $OUTPUT  [processing chain]

Per brevità e semplicità, visto che il resto non cambia, di seguito mi limito a specificare solo l'ultima parte (processing chain), in forma "simbolica", cominciando con i due casi che conosciamo già:

1) PCM->PCM:

 [gain reduction] [pre-res-effects] [resampling] [post-res-effects] [dithering]

2) PCM->DSD:

 [gain reduction] [pre-res-effects] <resampling> [post-res-effects] <sdm>

3) DSD->DSD:

<lowpass filter> [gain reduction] [pre-res-effects]  [resampling]  [post-res-effects] <sdm> 

4) DSD->PCM:

 <lowpass filter> [gain reduction] [pre-res-effects] <resampling> [post-res-effects] [dithering]

Come è evidente, i primi due due casi (ingresso PCM) sono pressoché identici, salvo due differenze: la sostituzione del dithering (opzionale) con "sdm" (obbligatorio per l'uscita DSD) ed il resampling, che ovviamente per il DSD è necessario per raggiungere il s/r di uscita (mentre per il pcm serve solo nel caso si desideri un s/r di uscita diverso da quello di ingresso).

Idem per gli altri due casi (ingresso DSD), identici ai primi due salvo l'aggiunga del filtro passa-basso (obbligatorio) in ingresso (conversione dsd2pcm), prima di qualsiasi altra elaborazione (incluso "gain -h"):

Qui un esempio:

$ AUDIODEV=hw:0,0 /opt/sox-dsd/bin/sox -S -V3 pippo.dsf -b 32 -t alsa lowpass -2 22k gain -h rate -vMn $[ 4 * 48000 ] dither -s -p 24

/opt/sox-dsd/bin/sox:      SoX v14.4.2

Input File     : 'pippo.dsf'
Channels       : 2
Sample Rate    : 5.6448e+06
Precision      : 1-bit
Duration       : 00:04:24.63 = 1493764608 samples ~ 19847 CDDA sectors
File Size      : 373M
Bit Rate       : 11.3M
Sample Encoding: 1-bit Direct Stream Digital
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no


Output File    : 'hw:0,0' (alsa)
Channels       : 2
Sample Rate    : 192000
Precision      : 32-bit
Duration       : 00:04:24.63 = 50808320 samples ~ 19847 CDDA sectors
Sample Encoding: 32-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

/opt/sox-dsd/bin/sox WARN dither: no `shibata' filter is available for rate 192000; using sloped TPDF
/opt/sox-dsd/bin/sox INFO sox: effects chain: input      5.6448e+06Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: lowpass    5.6448e+06Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: gain       5.6448e+06Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: rate        192000Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: dither      192000Hz  2 channels
/opt/sox-dsd/bin/sox INFO sox: effects chain: output      192000Hz  2 channels
In:100%  00:04:24.63 [00:00:00.00] Out:50.8M [      |      ]        Clip:0
Done.

salvo ciò che metti dopo "-t" nelle definizioni del formato di in e/o out non dovrebbe cambiare nulla, come al solito.

ma nell conversione PCM -> DSD <> 64, non era necessario un doppio effetto rate?

puoi fornitrmi il comando 'eseguibile' per convertire flac 44100/16 in DSD128 ?

grazie.

[UnixMan]

ma nell conversione PCM -> DSD <> 64, non era necessario un doppio effetto rate?

Uh? no, perché mai?

puoi fornitrmi il comando 'eseguibile' per convertire flac 44100/16 in DSD128 ?

ad es. quello che sto usando con LMS?

[17-02-12 14:03:28.9797] Slim::Player::TranscodingHelper::getConvertCommand2 (446) Matched: flc->dsf via: [flac] -dcs --totally-silent $START$ $END$ -- $FILE$ | [sox] -q  -t wav - -t dsf  -b 1 - gain -h rate -vMn 5644800 sdm -f  sdm-8

se ne vuoi uno analogo, eseguibile da cmd line:

sox -S -V3 infile.flac -t dsf -b 1 outfile.dsf gain -h rate -vMn $[ 2 * 2822400 ] sdm -f sdm-8

N.B.: "$[ 2 * 2822400 ]" è banalmente una sintassi di shell che fa il conto e sostituisce il valore ottenuto (2*2822400=5644800). Quindi se ci metti "1" ottieni DSD64, con 2 DSD128, con 4 DSD256, ecc. Puoi anche scriverci direttamente il valore che ti serve (che in linea di principio potrebbe essere qualsiasi, non necessariamente limitato a quelli standard), ma così è più comodo se vuoi fare prove con DSD64/128/ecc.

[marcoc1712]

Scusa, ormai mi perdo...

intendevo questo:

DSD -> DSD

sox in.dsf out.dsf rate -v 88200 gain 6 rate -v 11289600 sdm

come hai postato tu qui: http://www.nexthardware.com/forum/pc...tml#post971398.

[UnixMan]

intendevo questo:

DSD -> DSD

sox in.dsf out.dsf rate -v 88200 gain 6 rate -v 11289600 sdm

come hai postato tu qui: http://www.nexthardware.com/forum/pc...tml#post971398.

mmh, non so perché avessi scritto quel comando. Forse lo avevo scopiazzato da qualcosa che avevi postato in precedenza, preso da Daphile?

Comunque, non mi pare necessario fare quel doppio resampling down/up: in sostanza, l'effetto del primo è lo stesso che si ottiene banalmente con il semplice passa-basso.

L'unico vantaggio è che le eventuali elaborazioni "interne" (tra i due "rate") lavorano con un s/r molto più basso e perciò, nel caso di elaborazioni complesse (direi non sia il caso di gain e simili), è possibile che (nonostante il carico di lavoro extra prodotto da "rate" in ingresso) l'utilizzo complessivo di risorse (CPU e memoria) sia più basso rispetto a mantenere lo stream "interno" al s/r di ingresso. Per contro è piuttosto probabile che si producano molti più artifatti...

[marcoc1712]

Punto:

a. SOX

Le prove di debug inMS VS 2015 hanno veìvidenziato un probabile errore di configurazione del progetto, almeno per Win32 come target, si blocca proprio sul sdm ed in particolare sulla definizione dei filtri per SS2.

Con ogni probabilità manca una ottimizzazione del progetto per esere compilato con supporto a AVX o SS2 - ove possibile - ed un fault back ove non lo è. Il fatto che compilato in linux con target win32 funzioni...

Per me è come andare a caccia di lucciole in febbraio, quindi ho scritto a mansr al riguardo, chiedendogli anche di allineare msvc alla nuova versione, così da poter togliere di mezzo il mio repository.

Se qualcuno (Paolo) volesse provare (in linux) la nuova versione, sarebbe opportuno, se va, magari poi produce anche la versione per win.

b. squeezelite

non ho ancora fatto nulla in merito alle nuove patch, vorrei capire se sono indispensabili, utili o supeflue ai nostri usi.

c. c-3PO

Sto ancora tentando di chiarirmi le idee su quali siano i comandi da emetterenelle diverse condizioni.


IN GENERALE:

è oggi possibile usare LMS + Squeezelite-R2 (versione patchata) per riprodurre DSD convertito runtime su LMS usando la versione di SOX da noi patchata. In Linux è possibile uscire da squeezelite anche in 'nativo'.

Sono in corso verifiche per OsX.

QUesto è già un risultato completo, pur se 'artigianale', per quanto mi riguarda un primo rilascio di squeezelite-R2 'pacchettizzato' con le funzionalità necessarie potrà avvenire quando avrò conferma del corretto funzionamento anche in OsX, magari aggiungendo altre patch, se ritenuto indispensabile (io non riesco a provare).

Per quanto riguarda C-3PO, vedrò di rilasciarne una versione con supporto MINIMO a dsd in tempi brevi, parallelamente a squeezelite-R2, qundo avrò caito in via defintiva la sinassi dei comandi per le diverse situazioni.

Pre requisito è che SOX nella versione desiderata risulti disponibile (e compilabile) per tutte le piattaforme.

Chiedo scusa, ma tutto il processo è estremamente rallentato e molto poco efficace, dato che dipendo a altri per tutte le prove, se qualcuno vuole raccogliere il testimone e proseguire da qui in poi, è il benvenuto, ma così non riesco a garantire la qualità usuale e non mi va di mettere in giro altro software 'bacato' perchè non testato, ce n'è già troppo...