DSD in LMS con SOX

[marcoc1712]

Trovato un primo problema, non mortale, con SOX/DSD: il loudness va in errore, tocca disabilitarlo.

[UnixMan]

Trovato un primo problema, non mortale, con SOX/DSD: il loudness va in errore, tocca disabilitarlo.

mmh, in quali condizioni? Con DSD in ingresso o sempre?

[marcoc1712]

G:\Documents and Settings\marco\Desktop\SOX>sox -V3 -S -t dsf "F:\dsf_2822400.dsf
" -t wav -r 384000 -b 24 --buffer=8192 "F:/fromDfsToWav.wav" lowpass -2 22000  g
ain -h loudness -6 65 remix -m 1v0.94 2 rate -v -L -n -t -a -b 99 -f 384
000  dither -f modified-e-weighted -p 24
sox:      SoX v14.4.2-msvc

Input File     : 'F:\dsf_2822400.dsf'
Channels       : 2
Sample Rate    : 2.8224e+06
Precision      : 1-bit
Duration       : 00:02:09.40 = 365218560 samples ~ 9705 CDDA sectors
File Size      : 0
Bit Rate       : 0
Sample Encoding: 1-bit Direct Stream Digital
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no


Output File    : 'F:/fromDfsToWav.wav'
Channels       : 2
Sample Rate    : 384000
Precision      : 24-bit
Duration       : 00:02:09.40 = 49689600 samples ~ 9705 CDDA sectors
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comment        : 'Processed by SoX'

praticamenbte tutte le opzioni attive, tolgo loudness e va (fatta la prova togliendole 1 ad 1). Errore di "eccezione software sconosciuta" su alert, non esce nulla a terminale.

[UnixMan]

praticamente tutte le opzioni attive, tolgo loudness e va (fatta la prova togliendole 1 ad 1). Errore di "eccezione software sconosciuta" su alert, non esce nulla a terminale.

confermo. Anche su Linux, esce "Segmentation fault". Togliendo loudness va.

Il problema si presenta solo entrando in DSD: se in ingresso metti un PCM, non ci sono problemi. Se sposti tutta l'elaborazione dopo una conversione "più completa" a PCM, cioè dopo "rate", funziona:

sox-dsd -V3 -S test64-sdm8.dsf -t wav -r 384000 -b 24 --buffer=8192 pippo.wav lowpass -2 22000 rate -v -L -n -t -a -b 99 -f 384000 gain -h loudness -6 65 remix -m 1v0.94 2  dither -f modified-e-weighted -p 24

Forse prima di "rate", trattando il DSD solo con un p/b del 2o ordine, "non ci sono abbastanza bit"...

[UnixMan]

P.S.: ieri sera ho fatto un altro po' di test, questa volta utilizzando "sinc" per creare dei filtri p/b più ripidi... decisamente meglio. Con una cosa così:

time sox-dsd -S -V3 test64-sdm8.dsf test64-to-128-sinc+gain+6-rate5.dsf sinc -22k -t 48k gain +6 rate -v $[ 2 * 2822400 ] sdm -f sdm-8

real    0m26.345s
user    0m26.080s
sys     0m0.188s

il file DSD "upsamplato" è quasi identico ad un altro prodotto direttamente a DSD128 a partire dal file originale di partenza. Tagliando più alto e/o con filtri più blandi no, resta una marea di rumore residuo dal DSD64.

Questo è il risultato con il comando qui sopra:

Nell'immagine qui sopra, la traccia (stereo) in alto è un file PCM convertito prima a DSD64 e poi "upsamplato" a DSD128; quella in basso è il medesimo file PCM convertito direttamente a DSD128. Stessa cosa qui sotto, dove però il file "upsamplato" è stato ottenuto tagliando più in alto, sebbene con un filtro più ripido (sinc -44k -t 25k):

[marcoc1712]

P.S.: ieri sera ho fatto un altro po' di test, questa volta utilizzando "sinc" per creare dei filtri p/b più ripidi... decisamente meglio. Con una cosa così:

time sox-dsd -S -V3 test64-sdm8.dsf test64-to-128-sinc+gain+6-rate5.dsf sinc -22k -t 48k gain +6 rate -v $[ 2 * 2822400 ] sdm -f sdm-8

real    0m26.345s
user    0m26.080s
sys     0m0.188s

il file DSD "upsamplato" è quasi identico ad un altro prodotto direttamente a DSD128 a partire dal file originale di partenza. Tagliando più alto e/o con filtri più blandi no, resta una marea di rumore residuo dal DSD64.

Questo è il risultato con il comando qui sopra:

Nell'immagine qui sopra, la traccia (stereo) in alto è un file PCM convertito prima a DSD64 e poi "upsamplato" a DSD128; quella in basso è il medesimo file PCM convertito direttamente a DSD128. Stessa cosa qui sotto, dove però il file "upsamplato" è stato ottenuto tagliando più in alto, sebbene con un filtro più ripido (sinc -44k -t 25k):

Quindi devo riscrivere tutt al a sezione dei filtri?

v 2.0 = quello che mi avei detto, v. 2.x quando avrai raggiunto un anuova dieifizione, vedremo,ma io vado appena più lento a scriverli in C-3PO...

[marcoc1712]

confermo. Anche su Linux, esce "Segmentation fault". Togliendo loudness va.

Il problema si presenta solo entrando in DSD: se in ingresso metti un PCM, non ci sono problemi. Se sposti tutta l'elaborazione dopo una conversione "più completa" a PCM, cioè dopo "rate", funziona:

sox-dsd -V3 -S test64-sdm8.dsf -t wav -r 384000 -b 24 --buffer=8192 pippo.wav lowpass -2 22000 rate -v -L -n -t -a -b 99 -f 384000 gain -h loudness -6 65 remix -m 1v0.94 2  dither -f modified-e-weighted -p 24

Forse prima di "rate", trattando il DSD solo con un p/b del 2o ordine, "non ci sono abbastanza bit"...

Quindi cosa dovrei fare?

Spostare tutto o solo il loudness dopo il rate? solo per DSD in input o sempre? Ma il gain non deve stare prima del rate per impedire il clipping?

[UnixMan]

Quindi devo riscrivere tutt al a sezione dei filtri?

v 2.0 = quello che mi avei detto, v. 2.x quando avrai raggiunto un anuova dieifizione, vedremo,ma io vado appena più lento a scriverli in C-3PO...

sì, temo ci sarà da fare qualche variazione.

Ma, come giustamente dici... un passo alla volta. Inutile cambiare troppe cose adesso, rischiando di doverle cambiare di nuovo più avanti. Prima bisogna testare bene le cose, anche all'ascolto. E qui ci vogliono collaboratori con buoni impianti ed orecchio fino...

[UnixMan]

Quindi cosa dovrei fare?

Spostare tutto o solo il loudness dopo il rate? solo per DSD in input o sempre? Ma il gain non deve stare prima del rate per impedire il clipping?

SOLO quando l'ingresso è DSD, devi spostare qualsiasi elaborazione verso l'uscita, "a valle" di rate... ma ovviamente prima dell'eventuale dithering.

A proposito di quest'ultimo, bisognerebbe prevedere la possibilità di un trattamento diverso quando l'ingresso è PCM rispetto a quando è DSD (cioè opzioni dedicate separate). Arrivando dal DSD di rumore HF ce n'è già fin troppo... per cui non so se aggiungerne altro (dithering in uscita) possa essere controproducente anziché vantaggioso.

Problemi di clipping non ce ne sono. Anzi, è il contrario: bisognerebbe addirittura aumentare il gain, dato che il DSD "esce basso".

Al contrario, elaborare il segnale ancora "mezzo DSD" (pochi bit realmente utilizzati) rischia di causare una perdita di qualità sensibile (introdurre livelli di rumore relativamente elevati, anche in banda). Inoltre ci sono considerazioni di efficienza: un conto è elaborare un flusso a 192 o 384 k, ben altro farlo a oltre 2 MHz! (o addirittura 5+ se DSD128, ecc).

[marcoc1712]

SOLO quando l'ingresso è DSD, devi spostare qualsiasi elaborazione verso l'uscita, "a valle" di rate... ma ovviamente prima dell'eventuale dithering.

A proposito di quest'ultimo, bisognerebbe prevedere la possibilità di un trattamento diverso quando l'ingresso è PCM rispetto a quando è DSD (cioè opzioni dedicate separate). Arrivando dal DSD di rumore HF ce n'è già fin troppo... per cui non so se aggiungerne altro (dithering in uscita) possa essere controproducente anziché vantaggioso.

Problemi di clipping non ce ne sono. Anzi, è il contrario: bisognerebbe addirittura aumentare il gain, dato che il DSD "esce basso".

Al contrario, elaborare il segnale ancora "mezzo DSD" (pochi bit realmente utilizzati) rischia di causare una perdita di qualità sensibile (introdurre livelli di rumore relativamente elevati, anche in banda). Inoltre ci sono considerazioni di efficienza: un conto è elaborare un flusso a 192 o 384 k, ben altro farlo a oltre 2 MHz! (o addirittura 5+ se DSD128, ecc).

1.il dither è ovviamente riservato solo al PCM (come fai ad applicarlo ad uno stream di profondità = 1 bit?) così come i filtri SDM sono solo per DSD.

2. spostare TUTTI gli effetti dopo il rate ha un senso se da dsd (maggiore è la risoluzione, maggiore è il senso) passi a pcm 96KHz, ma se passi da DSD64 a pcm 384 KHz ha molto meno senso, a mio avviso. Comunque, va bene, se devo spostare il loudness non mi costa nulla spostare anche TUTTO il resto (basta che il blocco 'effetti' sia unico.

3. l'aggiunta del filtro di ingresso è la cosa più costosa in termini di CPU, prova a passarci un file in DSD256 o 128 e vedi cosa succede.Il problema non è la frequenza (che è un dato fittizio, dato che NESSUNA applicazione tratta 1 bit, ma sempre e solo word di multipli di 8) quel che conta è il troughput complessivo; PCM 44100 * 16 bit = 1.41 Mb/s pcm ma 768 * 32 = 49.15 Mb/, mentre dsd256 è 22.58.

Secondo me - ma vado a naso -l'approccio migliore sarebbe mettere gli effetti dove lo stream è più leggero, quindi normalmente lato PCM, ma volendo, il downsampling sarebbe da approcciare al contrario. Lo stesso, in linea di principio per DSD->DSD. Bisognerebbe però produrre una casistica esaustiva (e verificata) non vorrei incappare in idiosincrasie o incompatibilità varie.

Detto questo, L'utilizzo di SOX da riga di comando ( da custom-convert.conf) è certamente più flessibile di un qualsiasi strumento 'organizzato' e non è nelle mie intenzioni scrivere la webgui di SOX per poi doverla manutenere in continuazione, considerando poi che con gli extra effects si possono gestire situazioni complesse quanto si vuole, credo che c-3PO sia già abbastanza completo e per il momento si ferma qui, meglio fornire una soluzione imperfetta che nessuna soluzione.

Se mai mi convincerò, potrò mettere in cantiere la versionne 3.x con i supermega filtri ed opzioni, vedremo. Però, visto che c'è un modo standard ped definire i filtri (FIR) perchè non ti concentri nel trovare un modo di definirli compessi a piacere e passarli in input a SOX in un file di definzione? L'interfaccia sarebbe banale e le potenzialità quasi illimitate, senza contare che i FIR sono portabili, anche se io non avrei idea di dove cominciare...