DSD in LMS con SOX

[marcoc1712]

come dicevo, non ho ben chiaro se e quale possa essere l'utilità di aggiungere quel filtro.

Se parliamo di conversione PCM->DSD, partendo da uno stream PCM con sample-rate inferiori a 100K, evidentemente frequenze superiori a 50K non ce ne possono essere (e non sono neanche rappresentabili). Quindi quel filtro non ha senso. Ed infatti (giustamente) se provi a mettercelo sox dà errore:

E' per questo che io avevo pensato fosse DOPO il rate. Comunque, l'unico senso di convertire in DSD ed upsamplare è di spostare il rumore generato dai fitri (modulatori) in zone non udibili, se fosse sufficiente semplicemnet eliminare i dati con un filtro... per chè ci dovremmo tenere tutti qui giga inutili?

Perchè generiamo informazioni inesistenti sopr ai 22KHz fino a 400 Khz e più per poi tagliarle con un filtro a 50K?

mi sa che mi sfugge qualcosa...

Non è che per caso hai fatto confusione con le impostazioni relative all'upsampling del DSD (DSD->DSD)?

Tutto può essere ci riguardo.

In quel caso il filtro forse ha un senso, per "eliminare" (ridurre) il rumore fuori banda prima dell'upsampling(*).

In caso contrario, un lowpass a 50K puoi metterlo solo se lo stream PCM di partenza ha un s/r > 100K.

(*) personalmente proverei a "tagliare" anche molto più in basso di 50K: non solo non siamo delfini né pipistrelli ma, soprattutto, il resto della catena audio ed in modo particolare i diffusori ben difficilmente sono in grado di riprodurre correttamente frequenze oltre i 20K. Quanto meno, non molto oltre...

mmmhhh... questo è anche il mio dubbio 'originario' ma essendo così 'gnucco' propendo al che ci sia una spiegazione più complessa, v. sopra. (...mi sa che mi sfugge qualcosa...)

BTW: se non ho capito male come funzionano le cose, internamente sox lavora -sempre- in PCM a 32bit. Quindi, anche se in ingresso gli mandi uno stream DSD, lui rappresenta ogni "campione" (bit del DSD) con 32bit! Cioè per così dire lo "converte in PCM" (uno stream PCM dove tutti i bit tranne il LSB sono sempre a 0) allo stesso s/r dello stream DSD in ingresso (...ecco perché per poter "trattare" il DSD non solo ci vuole una CPU veloce, ma anche una quantità di memoria esagerata).

Secondo me non è così, l'opzione -b 1 serve proprio a dirgli di usare campioni da 1 bit (per canale).

Sia nel caso di PCM->DSD che DSD->DSD il processo prevede dapprima un "normale" upsampling (PCM) fino al sample/rate desiderato in uscita (quello del DSD 64/128/256), a 32bit (!), dopo di che (con sdm) viene applicato il dithering/noise-shaping ad 1bit.

Si è così, ma in uscita il flusso è a 1 bit, ma non credo possa essere diversamente.

[antonellocaroli]

con poco margine, ma il vecchietto ce la fa anche in DSD128:

a 256 come diventano i tempi ?

[UnixMan]

molte delle quali non sono documentate [...] sono definite: Primarily for test/development purposes

...ed ecco spiegato perché non sono documentate, se non all'interno dei sorgenti.

...però giochcchiarci un po con c-3Po...

sarebbe un'ottima idea.

Ovviamente devi indicare chiaro e forte che si tratta di opzioni sperimentali... e tenere conto che potrebbero essere modificate/sostituite o rimosse in versioni successive di sox.

N.B.: bisogna prestare attenzione al fatto che alcune di queste potrebbero essere in conflitto tra loro e/o con alcune delle altre opzioni "ufficiali", e bisogna vedere quali opzioni hanno il sopravvento sulle altre (la stessa cosa è vera anche per alcune delle opzioni documentate).

Perciò (anche solo con le opzioni documentate) occhio a "spippolare" a casaccio... si rischia di ottenere risultati diversi da ciò che si vorrebbe, e non capire il perché.

[marcoc1712]

...ed ecco spiegato perché non sono documentate, se non all'interno dei sorgenti.

e le altre (es. -f) ?

Comunque, se sono SOLO ad uso del debug, ...dovrebbereo essere DISABILITATE quando non in debug o almeno riportate come RISERVATE nella docuentazione. altrimenti un poverello le trova usate, si chiede perchè e cosa fanno, quindi gli tocca guardarsi il sorgente...

Non ci troveremo mai daccordo sui principi di ergonomia delle interfacce (non solo grafiche e non solo utente), questa è PESSIMA.

[marcoc1712]

Curiosamente, tra sdm-4 , 5, ... sdm-8 sembra cambiare ben poco

Verifico, comunque quelli sono 'solo' FIR, mansr stesso ammette che sono ottimizati solo per DSD64, usarli per SR superiori non porta danno ma nemmeno particolare beneficio, quindi probabilmente non aggiungono nemmeno troppo lavoro, specie su files di dimensioni modeste..

Per come è fatto SOX, bisognerebbe provare con fies ben più grandi, dato che spesso usa files temporanei (creati in memoria ma poi necessariamente paginati, ad un certo punto), il che può sensibilmente peggiorare le performances.

[UnixMan]

E' per questo che io avevo pensato fosse DOPO il rate. Comunque, l'unico senso di convertire in DSD ed upsamplare è di spostare il rumore generato dai fitri (modulatori) in zone non udibili, se fosse sufficiente semplicemnet eliminare i dati con un filtro... [...] mi sa che mi sfugge qualcosa...

sì. Più ci penso e più mi convinco che quel filtro è utile - ed indispensabile - (solo) quando fai "upsampling" da DSD a DSD.

Infatti, se non elimini (attenui quanto più possibile) il rumore del DSD64 in ingresso, non avrebbe alcun senso fare un "upsampling" da DSD64 a DSD128 o 256: tutto il rumore del DSD64 te lo ritroveresti tal quale in uscita, cui andrebbe solo a sommarsi quello (a freq. maggiore) aggiunto dopo da sdm.

Viceversa, eliminando a priori il rumore (a freq. più basse) del DSD64, in uscita hai solo quello (a freq. maggiori) prodotto da sdm... e quindi hai ottenuto il risultato voluto (cioè "spostare" il rumore più in alto, "allontanandolo" dalla banda utile).

Sox internamente lavora sempre in PCM a 32bit... altrimenti avrebbe dovuto essere riscritto praticamente da zero tutto quanto (cosa che non è stata fatta). Sono soltanto i processi di ingresso e di uscita che lavorano con formati diversi.

Con il lowpass in pratica trasformi lo stream interno da "PCM monobit" (DSD rappresentato con il LSB del PCM) a multibit (cioè in vero PCM, con il s/r del DSD): è per questo che (internamente) puoi "buttare via" il rumore. Dopo di che, ovviamente, il rumore lo re-introduci quanto torni in DSD con "sdm".

In effetti, a maggior ragione è utile tagliare più in basso... ed anzi probabilmente farebbero molto comodo filtri con pendenze più elevate (si può fare... per ottenere il risultato basta mettere più "lowpass" in cascata).

Secondo me non è così, l'opzione -b 1 serve proprio a dirgli di usare campioni da 1 bit (per canale).

sì, ma sempre e solo relativamente ai processi di input e/o output. Internamente sox usa sempre lo stesso formato, PCM 32bit, a prescindere da cosa gli arrivi in ingresso e da ciò che butta fuori in uscita. Sono proprio i processi di "input" ed "output" che si occupano di fare le necessarie conversioni.

a 256 come diventano i tempi ?

a 256 il vecchietto (Core2 Duo E6550 @ 2.33GHz) non è abbastanza veloce per farlo in tempo reale:

$ time sox -S -V3 ZOOM0001_LR.wav -t dsf -b 1 test.dsf rate -vMn $[ 4 * 2822400 ] sdm -f sdm-8
[...]
sox INFO sox: effects chain: input        44100Hz  2 channels
sox INFO sox: effects chain: rate       1.12896e+07Hz  2 channels
sox INFO sox: effects chain: sdm        1.12896e+07Hz  2 channels
sox INFO sox: effects chain: output     1.12896e+07Hz  2 channels
In:100%  00:00:47.19 [00:00:00.00] Out:533M  [!=====|=====!] Hd:0.0 Clip:0
Done.

real    1m19.056s
user    1m18.488s
sys     0m0.504s

[marcoc1712]

Non è che per caso hai fatto confusione con le impostazioni relative all'upsampling del DSD (DSD->DSD)?

Questo è il segmento di Transcode che si occupa di resampling:

#
# Resampling
#
if [[ -n "${OUTRATE}" && "${OUTRATE}" != "${RATE}" ]]
then
    
    resample=$(jsonrpc ${CLIENTID} playerpref plugin.daphile:resample_setup \? | jq -r '.result._p2')
    [[ "${resample}" = "null" ]] && resample=""
    CUR_IFS=$IFS
    IFS=: sox=( ${resample} )
    IFS=${CUR_IFS}

    [[ "${sox[2]:-1}" != "0" ]] && sox_effects "gain" "$(echo ${sox[2]:-1} | awk '{print -$1}')"
    
    if [[ "${OUTRATE}" -ge $DSD64 ]]
    then
        #
        # Convert to DSD output
        #
        [[ "${RATE}" -ge $DSD64 ]] && sox_effects "lowpass" "50k"

        rate=$(jsonrpc ${CLIENTID} playerpref plugin.daphile:pcm2dsd_rate \? | jq -r '.result._p2')
        [[ "${rate}" =~ ^[0-9]+$ && ${rate} -gt 0 ]] && OUTRATE=${rate}
        sox_effects "rate" "-${sox[0]:-h}n" "${OUTRATE}"

        nsfilt=$(jsonrpc ${CLIENTID} playerpref plugin.daphile:pcm2dsd_nsfilt \? | jq -r '.result._p2')
        [[ "$nsfilt" =~ ^(sdm|clans)-[45678]$ ]] || nsfilt="sdm-4"
        sox_effects "sdm" "-f" "${nsfilt}"
        
        [[ "${OUTFORMAT}" =~ ^(dsf|dff)$ ]] || DOP=true
    else
        #
        # Resampled PCM output
        #
        sox_effects "rate" "-${sox[0]:-h}n" "${OUTRATE}"
        
        [[ "${OUTFORMAT}" = "wav" ]] && maxbits=$(jsonrpc ${CLIENTID} playerpref plugin.daphile:maxbits \? | jq -r '.result._p2')
        [[ ${maxbits:-0} -lt 24 ]] && maxbits=24
        [[ $BITS -lt ${maxbits} ]] && BITS=${maxbits}

        DOP=false
    fi
fi

EDIT: HAi ragione, " [[ "${RATE}" -ge $DSD64 ]] && sox_effects "lowpass" "50k"" si attiva solo se RATE è >= DSD64, mi ero confuso con OUTRATE (test precedente).

Quindi , per ricapitolare, la riga che utilizzerei in custom-convert.conf è:

wav dsf * *
    # FT:{START=--skip=%t}U:{END=--until=%v}
    [flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q  -t flac - -t dsf  -b 1 - rate -v 2822400 sdm -f sdm-4

Per l'upsampling dsf è analoga, ma con il filtro passabasso.

Cerco di capire le diverse opzioni di sdm e le differenze, nel frattempo potete giocare con quelle e con le 'novità' del rate (-n, -t, -f) e riferire, se le cose stanno così integrare il dsd in C-3PO è semplice.

Domanda: DSDPlay deve essere attivo anche nel caso di upsampling da PCM o solo per il DSD Nativo? qualcuno riesce a verificare?

Grazie.

[UnixMan]

e le altre (es. -f) ?

Comunque, se sono SOLO ad uso del debug,

non credo servano per il debugging... mi sembrano piuttosto features "sperimentali". Non ancora abbastanza testate e verificate per renderle pubbliche.

Verifico, comunque quelli sono 'solo' FIR, mansr stesso ammette che sono ottimizati solo per DSD64,

sei rimasto indietro.

...se leggi il topic su CA che ho postato l'altro giorno (o guardi dentro sdm.c) vedrai che ha implementato i filtri ottimizzati anche per 128 e 256.

Per come è fatto SOX, bisognerebbe provare con fies ben più grandi, dato che spesso usa files temporanei (creati in memoria ma poi necessariamente paginati, ad un certo punto), il che può sensibilmente peggiorare le performances.

infatti proprio quello può essere il problema. Non per caso (mi pare proprio lì su CA) dice che per usarlo (specie in real-time) ci vogliono quantità di memoria esagerate (>8GB di RAM).

[antonellocaroli]

Domanda: DSDPlay deve essere attivo anche nel caso di upsampling da PCM o solo per il DSD Nativo? qualcuno riesce a verificare?

Vado a memoria...DSDPlay deve essere attivo solo se si vuole convertire DSD nativo in PCM...ed é attivabile solo se si lancia squeezelite senza l´opzione -D...

a memoria eh...

[marcoc1712]

non credo servano per il debugging... mi sembrano piuttosto features "sperimentali". Non ancora abbastanza testate e verificate per renderle pubbliche.


sei rimasto indietro.

...se leggi il topic su CA che ho postato l'altro giorno (o guardi dentro sdm.c) vedrai che ha implementato i filtri ottimizzati anche per 128 e 256

DSD encoding with SoX
poi
DSD encoding with SoX - Page 2

Funzionano, ma devono ancora essere migliorati, in altre parole sono stati si 'ottimizati' per l'uso con i diversi set di istruzioni, cioè fanno le stesse cose in meno tempo, ma rimane lavoro da fare per renderli più efficaci, cioè fargli fare 'meglio' quello he devono fare.

Capisco male io? Sono, invece, già al livello di qualità raggiungibile con HQP come dicono gli iperborei?

EDIT:

Di fatto i filtri per diverso samplerate si attivano SOLO se compilati con supporto AVX (256) o SSE2 (128) altrimenti vengono comunque usate le versioni 64x.

Oltre filtri sdm di ordine 4-8, è disonibile un'altra famiglisa, sempre per 64,18 e 256 e sempre di ordine 4-8, che si richiama con "-f clans-x", dove x è l'oridine (4-8), quindi, in pratica, i filtri disponibili sono 8.

p.s.

Qualcuno ha le competenze per giudicare ed eventualmente definire ulteriori filtri?