Squeezeplay) | Stampa

Printable View

Visualizza 40 messaggi di questa discussione in una pagina

24-04-2016, 12:24
UnixMan
Quote:

Originariamente inviato da marcoc1712

Vorrei capire cosa bisognerebbe fare limitatamente al dithering/noise shaping, che possa funzionare con la versione corrente in LMS di SOX e sia utile in occasione di resampling, quindi NON a 44100 o nel downsampling, in alternativa all'opzione automatica di SOX.

IO conto queste opzioni alternative:

- Disabilitato
- TPDF (default)
- sloped TPDF
- shape noise with shibata filter
- filter lipshitz,
- filter f-weighted,
- filter modified-e-weighted,
- filter improved-e-weighted,
- filter gesemann,
- filter shibata (è un doppione?)
- filter low-shibata
- filter high-shibata.

mi sai dire quali di queste opzioni sono effettivamente utilizzabili per frequenze > 44100 ? Grazie.

"utilizzabili" (nel senso che se le metti non succede nulla "di brutto") lo sono tutte; effettivamente funzionali per s/r >48K solo TPDF e "sloped TPDF" (selezionando una delle altre con un s/r non supportato va automaticamente in fall-back su sloped TPDF).

In altre parole (ad uso e consumo degli utenti meno smaliziati) potresti limitarti a sostituire la attuale checkbox con un menù a tendina fatto grosso modo così:

Dithering options:
- auto/default (non aggiunge nulla alla riga di comando di sox)
- sloped TPDF (aggiunge -in fondo- "dither -S")
- disable/none (aggiunge -in cima- "-D", come la attuale CB)
Volendo potresti anche aggiungere una opzione "noise shaping" (che aggiunge in fondo "dither -s", oppure "dither -f shibata"), con una nota nell'help che spiega che quella opzione funziona solo per s/r pari a 44.1K e 48K, mentre negli altri casi è equivalente a selezionare "sloped TPDF".

(la stessa cosa vale anche per le altre opzioni "-f " ma, visto che al momento l'utilità sarebbe molto limitata, probabilmente conviene ometterle).

Manca la cosa potenzialmente più utile/interessante, cioè la possibilità di selezionare liberamente la precisione desiderata a valori diversi da (minori di) quella del formato di uscita (opzione "-p "), ma questa la si potrebbe utilizzare solo con versioni di sox più recenti di quella attualmente fornita da LMS, e per giunta se la metti sulla vecchia versione dà "syntax error" e non funziona nulla, per cui... meglio evitare.

Quote:

Originariamente inviato da marcoc1712

le opzioni di cui sopra, tranne Disabilitato, possono essere integrate con l'opzione "automatico" (-a)

quella è utile soltanto nei casi in cui si operino delle "trasformazioni" (e.g. "fade-in", "fade-out", ecc) solo su alcune porzioni e non su tutto il file (o lo stream). In pratica con "-a" sox dovrebbe "capire" quali parti sono state modificate e necessitano di (nuovo) dithering e quali no, e quindi applicare il dithering solo "localmente" alle porzioni interessate. Lavorando su tutto il file (e.g., resampling) è perfettamente inutile (è equivalente al default, per giunta con il rischio che non funzioni correttamente come avverte il manuale). Direi che per i nostri scopi non sia proprio il caso di prenderla in considerazione.

Quote:

Originariamente inviato da marcoc1712

e dalla versione 14.4.2

anche prima, di sicuro almeno dalla 14.4.1 (ma non la 14.3 che attualmente viene con LMS).

Quote:

Originariamente inviato da marcoc1712

anche dalla 'profondità' se diversa da quella dell'output (immagino se < 24, da 24 in su il dithering non serve), quali sarebbero le scelte possibili?

qualsiasi numero intero compreso tra 8 e 24 (inclusi).

Quote:

Originariamente inviato da marcoc1712

sono daccordo che è fuorviante dover deselezionare il dither con CB per poi reinserirlo come effetto.

la CB conviene toglierla proprio... quella possibilità la integri nel menù (vedi sopra).

Quote:

Originariamente inviato da marcoc1712

Potrei certamente farlo, anche se mi sembra di tornare nella logica dei custom-convert.conf, ma l'alternativa è costruire un'interfaccia completa su sox ed i suoi effetti, il che trascende i miei obiettivi iniziali.

infatti, IMHO è fuori questione. Una interfaccia veramente completa è improponibile (sarebbe più complessa di tutto LMS...), mentre qualsiasi altra cosa sarebbe limitata e limitante.

A scanso equivoci metti "le caselle" in fondo includendole entro una apposita sezione "opzioni avanzate", "solo per utenti esperti". ;)

Quote:

Originariamente inviato da marcoc1712

Il problema è sempre il supporto. SE decido di farlo, lo metto certamente dietro un pulsante stile 'advanced mode' con warning e disclaimer ed aggiungendo la 'simulazione' della riga di comando risultante, altrimenti rischia di diventare un incubo di richieste di supporto sulla sintassi dei vari comandi di sox e persone che scrivono che non funziona semplicemente perchè scrivono comandi sbagliati, esattamente com'era con LMS ed i custom-convert.conf. Senza contare che il test automatico diventa virtualmente impossibile o poco significativo.

infatti per quella sezione NON devi simulare nulla (salvo assicurarti che quello che ci viene scritto venga inserito correttamente e senza errori dove previsto), né fornire alcun supporto. Scrivicelo chiaro e tondo.

Quote:

Originariamente inviato da antonellocaroli

Fatto!! e funziona anche con sox 14.4.2 ;)

@Paolo come si fa a sostituire sox in linux?

installi sox con apt (se non ce l'hai già) e quindi banalmente cancelli (o rinomini, o sposti altrove) l'eseguibile fornito da LMS (e.g. /usr/share/squeezeboxserver/Bin/x86_64-linux/sox ). Se non lo trova nelle "sue" directories, LMS li cerca nel PATH di sistema (quindi usa quello installato in /usr/bin).
24-04-2016, 14:30
antonellocaroli

Una cosa che forse mi sta sfuggendo i filtri al dither tipo -f shibata -p 24 funziona solo se il file in origine é 44.1? o deve essere anche in uscita a 44.1 (cioé senza resample)?
24-04-2016, 14:47
UnixMan

Quote:

Originariamente inviato da antonellocaroli

Una cosa che forse mi sta sfuggendo i filtri al dither tipo -f shibata -p 24 funziona solo se il file in origine é 44.1? o deve essere anche in uscita a 44.1 (cioé senza resample)?

Il dithering si applica in uscita, alla fine (diversamente non avrebbe senso), per cui conta solo il s/r in uscita.

Alcuni sono implementati anche per 48K ma oltre purtroppo no, c'è solo lo "sloped TPDF".

Inviato dal mio GT-I9100 utilizzando Tapatalk
24-04-2016, 14:51
marcoc1712

Quote:

Originariamente inviato da antonellocaroli

Una cosa che forse mi sta sfuggendo i filtri al dither tipo -f shibata -p 24 funziona solo se il file in origine é 44.1? o deve essere anche in uscita a 44.1 (cioé senza resample)?

Uscita! Questo è il mio fondamentale dubbio di opportunità.

Facendo resample >48 KHz ti rimane solo la scelta di TPDF (standard) o sloped TPDF, con il mondo che ci dice che con profondità => 24 bit è del tutto inutile applicare qualsiasi forma di dithering (ed infatti SOX di suo non lo farebbe).

La scommessa di Paolo (che per questo ritiene fondamentale il -p) è che, in realtà, partendo da materiale a 16 bit non ci sia nessun vantaggio - anzi - nel portarlo a 24 o oltre 'matematicamente', quindi lo limiterebbe ,poniamo, a 16 applicando il dithering/noise shaping indipendentemente dalla frequenza di campionamento.

Io non ne ho idea, ma non ho ancora capito il vantaggio rispetto a fare l'upsampling SENZA cambiare la profondità ed, ovviamnete. applicando il dithering, ma sicuramente mi sfugge qualcosa.

Comunque, i miei dubbi sul 'reale' beneficio di upsampling, aumento di profondità, filtri e varie si stanno rafforzando, E' indubbio che qualche parametro mgliora, ma tornando ai 44100/16 nativi, in qualche misura è tutto più 'vero'.

Non ho ancora "lu Criaturu" però...
24-04-2016, 15:52
UnixMan

Quote:

Originariamente inviato da marcoc1712

Facendo resample >48 KHz ti rimane solo la scelta di TPDF (standard) o sloped TPDF, con il mondo che ci dice che con profondità => 24 bit è del tutto inutile applicare qualsiasi forma di dithering (ed infatti SOX di suo non lo farebbe).

fino a 24bit (inclusi) lo fa, è solo oltre che non lo fa comunque (neanche se glielo chiedi espressamente).

Quote:

Originariamente inviato da marcoc1712

La scommessa di Paolo (che per questo ritiene fondamentale il -p) è che, in realtà, partendo da materiale a 16 bit non ci sia nessun vantaggio - anzi - nel portarlo a 24 o oltre 'matematicamente', quindi lo limiterebbe ,poniamo, a 16 applicando il dithering/noise shaping indipendentemente dalla frequenza di campionamento.

ehm... precisiamo: non si tratta di una "scommessa", ma solo di una ipotesi/dubbio, tutta da verificare.

Un altro dubbio -diverso- è invece relativo al fatto che la dinamica/risoluzione effettiva dei DAC, anche nei casi migliori, è sempre sensibilmente inferiore a quella dei 24 o addirittura 32 bit che questi possono accettare in ingresso. Per cui mi viene da pensare che forse potrebbe essere più opportuno applicare il dithering ad una risoluzione pari (o leggermente inferiore, comunque non superiore) a quella di cui è realmente capace il DAC che si utilizza.

Per finire, ci sono ancora in circolazione (e molti utilizzano con soddisfazione) dei vecchi e gloriosi DAC che hanno risoluzioni di 20, 18, 16 o addirittura 14 bit (e.g., quelli basati sul venerando TDA1540). Per questi è fuor di dubbio che il dithering va necessariamente applicato quanto meno ad una precisione non superiore a quella max supportata (in ingresso) dal DAC. Sfortunatamente, tranne che nel caso di quelli a 16bit (in cui il risultato si può ottenere selezionando 16 bit come formato di uscita), per tutti gli altri l'unico modo di ottenere il risultato è quello di utilizzare una versione aggiornata di sox con l'opzione "dither -p XX".

N.B.: se in C-3PO si seleziona un formato di uscita a 32bit, sox non effettua mai il dithering, neanche se glielo si richiede espressamente aggiungendo l'effetto "dither" alla sua riga di comando (a meno che non ci sia anche l'opzione "-p XX", con XX<=24, cosicché i 32bit diventano fittizi e la precisione di uscita ridotta al valore "XX").
24-04-2016, 17:08
marcoc1712

Quote:

Originariamente inviato da UnixMan

fino a 24bit (inclusi) lo fa, è solo oltre che non lo fa comunque (neanche se glielo chiedi espressamente).

ehm... precisiamo: non si tratta di una "scommessa", ma solo di una ipotesi/dubbio, tutta da verificare.

Un altro dubbio -diverso- è invece relativo al fatto che la dinamica/risoluzione effettiva dei DAC, anche nei casi migliori, è sempre sensibilmente inferiore a quella dei 24 o addirittura 32 bit che questi possono accettare in ingresso. Per cui mi viene da pensare che forse potrebbe essere più opportuno applicare il dithering ad una risoluzione pari (o leggermente inferiore, comunque non superiore) a quella di cui è realmente capace il DAC che si utilizza.

Per finire, ci sono ancora in circolazione (e molti utilizzano con soddisfazione) dei vecchi e gloriosi DAC che hanno risoluzioni di 20, 18, 16 o addirittura 14 bit (e.g., quelli basati sul venerando TDA1540). Per questi è fuor di dubbio che il dithering va necessariamente applicato quanto meno ad una precisione non superiore a quella max supportata (in ingresso) dal DAC. Sfortunatamente, tranne che nel caso di quelli a 16bit (in cui il risultato si può ottenere selezionando 16 bit come formato di uscita), per tutti gli altri l'unico modo di ottenere il risultato è quello di utilizzare una versione aggiornata di sox con l'opzione "dither -p XX".

N.B.: se in C-3PO si seleziona un formato di uscita a 32bit, sox non effettua mai il dithering, neanche se glielo si richiede espressamente aggiungendo l'effetto "dither" alla sua riga di comando (a meno che non ci sia anche l'opzione "-p XX", con XX<=24, cosicché i 32bit diventano fittizi e la precisione di uscita ridotta al valore "XX").

mmhh, io la capisco diversamente:

codice:

Specifically, by default, SoX automatically adds TPDF dither when the output bit-depth is less than 24 and any of the following are true: • bit-depth reduction has been specified explicitly using a command-line option • the output file format supports only bit-depths lower than that of the input file format • an effect has increased effective bit-depth within the internal processing chain

Solo < 24bit, 24 no, il che vuol dire che senza -p devo uscire a 16, ma non credo che 16 con dither sia meglio di 24 senza dither, ammesso il dac arrivi a 24.

-p sarebbe quindi utile per i dac con risoluzione minore (reale o fittizia) di 24 bit, per il solo fatto di permettere la riduzione a, poniamo, 20 bit per il mio DAC 1-20. Questo lo capisco ed effettivamente non c'è altro modo per uscire a 20bit 'reali'.

MA, quel vecchio DAC ed altri accettano davvero tutti i 20 bit in ingresso o 'tagliano' a 16 (come erano i formati un tempo) e poi usano 20 bit internamente nei loro filtri e arzigogoli?

Io non lo so, ma fosse così, allora sarebbe meglio NON aumentare la profonidtà in uscita ed applicare il dither ai 16 bit (se si fa resampling), sapendo che poi verrà comunque riapplicato dal DAC stesso, senza bisogno del -p.

Stai a vedere che il maggiore 'beneficiario' del menu a tendina per il dithering risulta essere il mio dac!

Come faccio a sapere che profondità in ingresso accetta un dac via SPDIF?

MI spiego: In ricevitore digitale è uno YM3623B; che dai datasheet sembra essere a 16 bit. Il filtro SM5803APT accetta input a 16 o 18 bit ed esce a 16,18 o 20. Solo il DAC (Ultra Analog D20400A) è un 'vero' 20 bit.

A me pare di capire che al massimo passano 16 bit per il ricevitore, meglio quindi lasciare tutto a 16?
25-04-2016, 00:03
UnixMan
Quote:

Originariamente inviato da marcoc1712

mmhh, io la capisco diversamente:
[...]
Solo < 24bit, 24 no,

in effetti pare proprio che, se l'uscita è a 24bit, di default sox non aggiunge (automaticamente) il dithering:

codice:

$ sox -V3 test32.wav -b24 test24.wav rate 48000 sox: SoX v14.4.1 sox INFO formats: detected file format type `wav' sox INFO wav: EXTENSIBLE Input File : 'test32.wav' Channels : 2 Sample Rate : 44100 Precision : 32-bit Duration : 00:05:06.66 = 13523530 samples = 22999.2 CDDA sectors File Size : 108M Bit Rate : 2.82M Sample Encoding: 32-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Output File : 'test24.wav' Channels : 2 Sample Rate : 48000 Precision : 24-bit Duration : 00:05:06.66 = 14719488 samples ~ 22999.2 CDDA sectors Sample Encoding: 24-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' sox INFO sox: effects chain: input 44100Hz 2 channels sox INFO sox: effects chain: rate 48000Hz 2 channels sox INFO sox: effects chain: output 48000Hz 2 channels

però, d'altro canto, se invece gli chiedo esplicitamente di aggiungerlo, lo fa senza protestare:

codice:

$ sox -V3 test16.flac -b24 test24.wav rate 96000 dither sox: SoX v14.4.1 sox INFO formats: detected file format type `flac' Input File : 'test16.flac' Channels : 2 Sample Rate : 48000 Precision : 16-bit Duration : 00:05:06.66 = 14719488 samples ~ 22999.2 CDDA sectors File Size : 21.8M Bit Rate : 569k Sample Encoding: 16-bit FLAC Endian Type : little Reverse Nibbles: no Reverse Bits : no Output File : 'test24.wav' Channels : 2 Sample Rate : 96000 Precision : 24-bit Duration : 00:05:06.66 = 29438976 samples ~ 22999.2 CDDA sectors Sample Encoding: 24-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' sox INFO sox: effects chain: input 48000Hz 2 channels sox INFO sox: effects chain: rate 96000Hz 2 channels sox INFO sox: effects chain: dither 96000Hz 2 channels sox INFO sox: effects chain: output 96000Hz 2 channels

se invece provo a fare altrettanto uscendo a 32bit, si rifiuta proprio di farlo: “sox INFO dither: has no effect in this configuration”...

codice:

$ sox -V3 test16.flac -b32 test32.wav rate 44100 dither sox: SoX v14.4.1 sox INFO formats: detected file format type `flac' Input File : 'test16.flac' Channels : 2 Sample Rate : 48000 Precision : 16-bit Duration : 00:05:06.66 = 14719488 samples ~ 22999.2 CDDA sectors File Size : 21.8M Bit Rate : 569k Sample Encoding: 16-bit FLAC Endian Type : little Reverse Nibbles: no Reverse Bits : no Output File : 'test32.wav' Channels : 2 Sample Rate : 44100 Precision : 32-bit Duration : 00:05:06.66 = 13523529 samples = 22999.2 CDDA sectors Sample Encoding: 32-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' sox INFO dither: has no effect in this configuration sox INFO sox: effects chain: input 48000Hz 2 channels sox INFO sox: effects chain: rate 44100Hz 2 channels sox INFO sox: effects chain: output 44100Hz 2 channels

Quote:

Originariamente inviato da marcoc1712

il che vuol dire che senza -p devo uscire a 16,

visto quanto sopra, no: basta uscire a 24bit ed aggiungere esplicitamente l'effetto "dither". Questo però significa che, se vuoi dare la possibilità di aggiungere dither TPDF (non "sloped") anche uscendo a 24bit devi aggiungere una ulteriore voce al menù (che aggiunge solo "dither", senza opzioni). Quindi il menù diventerebbe:
- auto/default (non aggiunge nulla)
- TPDF (aggiunge solo "dither")
- sloped TPDF (aggiunge "dither -S")
- noise shaping (aggiunge "dither -s")
- disabled/none (aggiunge "-D" in cima)
Quote:

Originariamente inviato da marcoc1712

ma non credo che 16 con dither sia meglio di 24 senza dither, ammesso il dac arrivi a 24.

se parti da 24bit, immagino proprio di no. Ma se invece parti da 16bit, questa è una delle domande a cui bisognerebbe rispondere... provando.

Quote:

Originariamente inviato da marcoc1712

MA, quel vecchio DAC ed altri accettano davvero tutti i 20 bit in ingresso o 'tagliano' a 16 (come erano i formati un tempo) e poi usano 20 bit internamente nei loro filtri e arzigogoli?

dipende dall'implementazione. Quelli "moderni" (ad es. i "NOS") di solito in ingresso accettano 24 o 32 bit (poi troncano brutalmente...).

Quote:

Originariamente inviato da marcoc1712

Stai a vedere che il maggiore 'beneficiario' del menu a tendina per il dithering risulta essere il mio dac!

chissà, è possibile... :D

Quote:

Originariamente inviato da marcoc1712

Come faccio a sapere che profondità in ingresso accetta un dac via SPDIF?

se intendi dal computer... non fai. :(

E non solo con i DAC collegati via S/PDIF. Non ci si può fare affidamento neanche con quelli USB, dato che l'informazione riportata dal sistema è quella fornita dall'interfaccia, che spesso si riferisce alle capacità/possibilità dell'interfaccia stessa, non a quelle effettive del DAC... come per altro è ovvio che sia, a meno che l'interfaccia non sia stata appositamente (ri)programmata per fornire i dati esatti relativi allo specifico DAC che c'è collegato a valle. Cosa che non sempre accade neanche per i prodotti commerciali integrati e che ovviamente non può accadere quando interfaccia USB e DAC sono due prodotti "indipendenti" (com'è ad es. il caso de "Il Criaturu", del mio AK4490, ecc).

Quote:

Originariamente inviato da marcoc1712

MI spiego: In ricevitore digitale è uno YM3623B; che dai datasheet sembra essere a 16 bit. Il filtro SM5803APT accetta input a 16 o 18 bit ed esce a 16,18 o 20. Solo il DAC (Ultra Analog D20400A) è un 'vero' 20 bit.

A me pare di capire che al massimo passano 16 bit per il ricevitore,

se effettivamente il ricevitore in ingresso non accetta più di 16bit, temo proprio di sì. Anche in caso contrario al max potresti arrivare a 18 per via del filtro.

Quote:

Originariamente inviato da marcoc1712

meglio quindi lasciare tutto a 16?

visto quanto sopra, mi pare probabile che sia proprio così. Prova...
25-04-2016, 06:04
antonellocaroli

Quote:

Originariamente inviato da UnixMan

installi sox con apt (se non ce l'hai già) e quindi banalmente cancelli (o rinomini, o sposti altrove) l'eseguibile fornito da LMS (e.g. /usr/share/squeezeboxserver/Bin/x86_64-linux/sox ). Se non lo trova nelle "sue" directories, LMS li cerca nel PATH di sistema (quindi usa quello installato in /usr/bin).

Comunque cambiando sox distribuito con LMS con quello scaricato di sicuro l'uso delle risorse migliorano (almeno nel mio caso) e di brutto:

Sox di sistema:
https://up.nexthardware.com/user_ima...dium/top2.jpeg

Sox di LMS:
https://up.nexthardware.com/user_ima...dium/top1.jpeg

Con windows non ho notato differenze..
25-04-2016, 12:01
UnixMan

Quote:

Originariamente inviato da antonellocaroli

Comunque cambiando sox distribuito con LMS con quello scaricato di sicuro l'uso delle risorse migliorano (almeno nel mio caso) e di brutto:

;blink1

Non è che avevi preso un "momento sbagliato"? (e.g., il "picco" in corrispondenza al riempimento del buffer di SL all'inizio di un brano?) Qualche differenza ci può stare (ottimizzazioni...), ed in effetti anche io ho notato una riduzione abbastanza significativa del consumo di risorse, ma non così eclatante. Una cosa così mi pare veramente esagerata. :oooo

Su che sistema? Che versione di sox?
25-04-2016, 12:12
antonellocaroli

Quote:

Originariamente inviato da UnixMan

;blink1

Non è che avevi preso un "momento sbagliato"? (e.g., il "picco" in corrispondenza al riempimento del buffer di SL all'inizio di un brano?) Qualche differenza ci può stare (ottimizzazioni...), ed in effetti anche io ho notato una riduzione abbastanza significativa del consumo di risorse, ma non così eclatante. Una cosa così mi pare veramente esagerata. :oooo

Su che sistema? Che versione di sox?

è su una ubuntu studio la versione l´ultima (no l´ultimissima)
la versione di sox installata da LMS non saprei...dovrei verificare...

Ma l´uso delle risorse alte in linux (da parte di LMS/SOX) le avevo notato da sempre nel mio sistema, anche con altre distro tipo debian, ( e io ho un i7-2600K overcloccato)...tanto che mi aveva fatto preferire sempre windows nel server...

l´ uso al 40 % della cpu é quasi fisso con sox di LMS

Ho vericato per bene e l´uso della cpu con sox del sistema scendono drasticamente...il motivo? non saprei

Visualizza 40 messaggi di questa discussione in una pagina