upsampling (universo LMS/Squeezelite/Squeezeplay)

[marcoc1712]

ERRORE!!!

1) per fare upsampling NON devi specificare "-r xxx" nel formato di uscita: il s/r desiderato devi metterlo tra i parametri del comando "rate"!

2) se il formato del file (stream) di ingresso non è "headerless" (raw), NON devi mai specificare le opzioni riguardanti il formato!!

Farlo significa fare un "override" di quanto scritto negli header del file, cioè significa forzare sox ad interpretare i dati contenuti del file in modo diverso da ciò che (presumibilmente) sono (ergo... esce solo "rumore").

3) anche per quanto riguarda il file di uscita, le opzioni di formato vanno usate con cura e parsimonia, fornendo solo quelle indispensabili, se e quando strettamente necessario!

Ad es., se fai resampling NON specificare mai il s/r nel formato di uscita: non solo è del tutto superfluo ma, se per sbaglio fornisci nelle opzioni del file un s/r diverso da quello chiesto a "rate", ottieni che rate venga chiamato DUE volte, la prima con le opzioni che gli hai dato e la seconda in modo automatico, con le opzioni di default, per riconvertire al formato di uscita richiesto.

Il comando corretto è questo:

sox -V3  file_di_ingresso.flac  file_di_uscita.wav  rate -v 192000

(poi, come detto, NON mettere "-D"! Casomai, al contrario, aggiungi un bel "dither -s" in fondo!)

Il -D serve ad evitare il dithering, io ne so poco, ma ovunque si dice di evitare eil dithering su materiale che lo ha già subito,

sox stesso dice:

Dithering is a technique used to maximise the dynamic range of audio stored at a particular bit-depth. Any distortion introduced by quantisation is decorrelated by adding a small amount of white noise to the signal. In most cases, SoX can determine whether the selected processing requires dither and will add it during output formatting if appropriate.

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

Quindi non nel nostro caso.

comunque non è questo il mio problema adesso, le opzioni di ottimizzazione le vedrà chi vorrà in seguito, il mio obiettivo è di trovare la struttura di comando giusto.

il -V3 è per vedere cosa fa nel dettaglio, a regime rimetteremo il -q.

-t flac sull'input si può omettere, corretto, ma solo fintanto che parti da un file, quando parti da un raw (in pipe con Flac) bisogna ripristinare tutta la sfilza dei parametri descrittivi, ponendo attenzione. Comunque non è vietato, è uno dei modi possibili per farlo.

Il file prodotto dal tuo comando è a 16 bit, per portarlo a 24, non conosco altro modo del -b 24 nelle opzioni relative al file di output, c'è un modo migliore?

Altro problema, se non metti una riduzione del volume, SOX avvisa che clippa, quindi io aggiungerei anche il -b 90

Quindi il comando diventa:

sox file_di_ingresso.flac -b 24 file_di_uscita.wav rate -v -b 90 192000[/CODE]

Che, se aggiungi il -D, produce esattamente lo stesso output (in termini di bit) del comando che ho postato io, quindi con gli stessi problemi di rumore se suonato da LMS su pc win ma non su mac o con foobar, da qui il motivo della richiesta.

Ovviamente togliendo il -D cambia qualche bit nel file (togliendo il -b 24 il file è - ovviamente - completamente diverso, anche come dimensione), ma non è quello che attualmente mi preoccupa, quindi ai miei fini vanno bene i file prodotti in entrambi i modi.

[UnixMan]

Il -D serve ad evitare il dithering, io ne so poco, ma ovunque si dice di evitare eil dithering su materiale che lo ha già subito,

infatti SOX lo aggiunge automaticamente (alla fine, come ultimo step) solo se ce n'è bisogno cioè se, nella sequenza di comandi che ha eseguito, c'è una operazione che ne richieda l'applicazione (ad es. una "riquantizzazione" con riduzione del "bit depth"). In caso contrario non lo fa:

In most cases, SoX can determine whether the selected processing requires dither and will add it during output formatting if appropriate.

l'opzione "-D" serve ad impedire che ciò venga fatto anche quando sox ritiene che sia opportuno farlo; va aggiunta solo per casi particolari, ad es. quando lo stream debba subire ulteriori elaborazioni e/o quando si voglia aggiungere il dithering a posteriori con un altro software.

Quindi non nel nostro caso.

invece può esserlo:

•an effect has increased effective bit-depth within the internal processing chain

il resampling con conversione da 16/44 a 24/192 (che in realtà è ottenuto con la sequenza: 16/44 -> 32/44 -> 32/192 -> 24/192) è proprio uno di questi casi.

-t flac sull'input si può omettere, corretto, ma solo fintanto che parti da un file, quando parti da un raw (in pipe con Flac) bisogna ripristinare tutta la sfilza dei parametri descrittivi, ponendo attenzione.

certamente ma, dato che il risultato è esattamente identico, non ha alcun senso complicarsi la vita inutilmente. Molto meglio lasciar fare tutto a sox, dandogli in pasto direttamente il file originale.

Il file prodotto dal tuo comando è a 16 bit, per portarlo a 24, non conosco altro modo del -b 24 nelle opzioni relative al file di output, c'è un modo migliore?

penso di no, quello dovrebbe essere corretto. Errore mio non aver specificato -b 24 in uscita. Probabilmente, se non diversamente specificato, il default in uscita è 16bit.

N.B.: considera che "internamente" SOX ignora quale sia il formato dei dati in ingresso ed in uscita: qualsiasi essi siano, la prima operazione che fa -sempre- è quella di convertire i dati in ingresso nel suo formato interno (PCM a 32bit), mentre l'ultima operazione che fa è quella di convertire nuovamente i dati elaborati dal suo formato interno a quello richiesto in uscita, eventualmente applicando le ulteriori elaborazioni richieste per ottenere tale formato (eventuali resampling, riduzione del bit-depth, dithering, ecc).

Per questo se tu dai il comando:

sox -V3 file_di_ingresso.flac -b 24 -r 192000 file_di_uscita.wav

ottieni effettivamente che venga effettuato (automaticamente) il resampling. Salvo che (come per tutte le operazioni automatiche) in tal caso vengono utilizzate le opzioni di default e NON hai modo di cambiarle.

Altro problema, se non metti una riduzione del volume, SOX avvisa che clippa, quindi io aggiungerei anche il -b 90

che c'entra l'opzione "-b" del comando "rate" (che cambia la banda passante del filtro di resampling) con il clipping?

Per evitare il clipping è necessario ridurre l'ampiezza del segnale (con il comando "gain") prima di procedere con le ulteriori elaborazioni.

Per questo suggerivo di aggiungere "gain -6" (prima di rate):

sox -V3 file_di_ingresso.flac -b 24 file_di_uscita.wav gain -6  rate -v 192000

(qualora -6dB non fossero sufficienti si può aumentare l'attenuazione ad es. a -9 o più. Viceversa la si può ridurre qualora fosse sufficiente una attenuazione minore).

P.S.: ovviamente è possibile che il filtro più semplice (di ordine inferiore) richiesto dalla minore banda passante (rate -b 90) riduca o addirittura elimini la probabilità di incorrere in "clipping" (overflow) durante i calcoli. Ma si tratta di una "soluzione" indiretta e limitante (nel senso che ti obbliga a scegliere determinate opzioni di resampling piuttosto che altre, mentre ovviamente vogliamo essere liberi di scegliere le opzioni di resampling che vogliamo, solo sulla base di quali "suonano" meglio nel nostro sistema). La soluzione "propria" e diretta è appunto quella di ridurre preventivamente il valore numerico dei campioni utilizzando la funzione "gain".

[marcoc1712]

Comando errato. Prova piuttosto:

-flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[sox] -V3 -t flac - -t wav -b 24 - rate -v 192000

Se il tuo DAC supporta stream a 32bit, anziché "-b 24" puoi provare anche con "-b 32" (meglio).

Puoi anche aggiungere "gain" per prevenire eventuali clipping:

-flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[sox] -V3 -t flac - -t wav -b 24 - gain -6 rate -v 192000

Spiegazione del comando di sox come da post precedente:

sox
-V3
-t flac -
-t wav -b 24 -
gain -6
rate -v 192000

Ovvero:

Comando errato. Prova piuttosto:

-flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[sox] -V3 -t flac - -t wav -b 24 - rate -v 192000

Se il tuo DAC supporta stream a 32bit, anziché "-b 24" puoi provare anche con "-b 32" (meglio).

Puoi anche aggiungere "gain" per prevenire eventuali clipping:

-flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[sox] -V3 -t flac - -t wav -b 24 - gain -6 rate -v 192000

Spiegazione del comando di sox come da post precedente:

sox
-V3
-t flac -
-t wav -b 24 -
gain -6
rate -v 192000

Ovvero:

sox
opzioni generali:	-V3	"verbose", scrive cosa sta facendo
definizione dello stream di ingresso:	-t flac -	stream da standard input, formato flac
definizione dello stream di uscita:	-t wav -b 24 -	stream su standard output, formato PCM wav a 24 bit
1° comando:	gain -6	attenua di 6dB
2° comando:	rate -v 192000	ricampiona a 192Ks/s, in modalità "VHQ"

infatti SOX lo aggiunge automaticamente (alla fine, come ultimo step) solo se ce n'è bisogno cioè se, nella sequenza di comandi che ha eseguito, c'è una operazione che ne richieda l'applicazione (ad es. una "riquantizzazione" con riduzione del "bit depth"). In caso contrario non lo fa:

l'opzione "-D" serve ad impedire che ciò venga fatto anche quando sox ritiene che sia opportuno farlo; va aggiunta solo per casi particolari, ad es. quando lo stream debba subire ulteriori elaborazioni e/o quando si voglia aggiungere il dithering a posteriori con un altro software.


invece può esserlo:

il resampling con conversione da 16/44 a 24/192 (che in realtà è ottenuto con la sequenza: 16/44 -> 32/44 -> 32/192 -> 24/192) è proprio uno di questi casi.


certamente ma, dato che il risultato è esattamente identico, non ha alcun senso complicarsi la vita inutilmente. Molto meglio lasciar fare tutto a sox, dandogli in pasto direttamente il file originale.


penso di no, quello dovrebbe essere corretto. Errore mio non aver specificato -b 24 in uscita. Probabilmente, se non diversamente specificato, il default in uscita è 16bit.

N.B.: considera che "internamente" SOX ignora quale sia il formato dei dati in ingresso ed in uscita: qualsiasi essi siano, la prima operazione che fa -sempre- è quella di convertire i dati in ingresso nel suo formato interno (PCM a 32bit), mentre l'ultima operazione che fa è quella di convertire nuovamente i dati elaborati dal suo formato interno a quello richiesto in uscita, eventualmente applicando le ulteriori elaborazioni richieste per ottenere tale formato (eventuali resampling, riduzione del bit-depth, dithering, ecc).

Per questo se tu dai il comando:

sox -V3 file_di_ingresso.flac -b 24 -r 192000 file_di_uscita.wav

ottieni effettivamente che venga effettuato (automaticamente) il resampling. Salvo che (come per tutte le operazioni automatiche) in tal caso vengono utilizzate le opzioni di default e NON hai modo di cambiarle.


che c'entra "-b" (che cambia la banda passante del filtro di resampling) con il clipping?

Per evitare il clipping è necessario ridurre l'ampiezza del segnale (con il comando "gain") prima di procedere con le ulteriori elaborazioni.

Per questo suggerivo di aggiungere "gain -6" (prima di rate):

sox -V3 file_di_ingresso.flac -b 24 file_di_uscita.wav gain -6  rate -v 192000

(qualora -6dB non fossero sufficienti si può aumentare l'attenuazione ad es. a -9 o più. Viceversa la si può ridurre qualora fosse sufficiente una attenuazione minore).

P.S.: ovviamente è possibile che il filtro più semplice (di ordine inferiore) richiesto dalla minore banda passante (rate -b 90) riduca o addirittura elimini la probabilità di incorrere in "clipping" (overflow) durante i calcoli. Ma si tratta di una "soluzione" indiretta e limitante (nel senso che ti obbliga a scegliere determinate opzioni di resampling piuttosto che altre, mentre ovviamente vogliamo essere liberi di scegliere le opzioni di resampling che vogliamo, solo sulla base di quali "suonano" meglio nel nostro sistema). La soluzione "propria" e diretta è appunto quella di ridurre preventivamente il valore numerico dei campioni utilizzando la funzione "gain".

Tutto giusto, tranne che per il -r, puoi dare anche le opzioni di rate, ma devi curare tu che -r ed il rate siano congruenti. Se esci raw sei obbligato.


Errore mio per il -b, chissà perchè mi ero fissato che fosse il volume.

Il problema è che qualsiasi cosa esca dopo un -t wav non va se è diverso da 44100/16. Almeno da mac, così come non vanno i files wav > 44100/16 se suonati da PC, facendo uscire raw da mac (con i parametri opportuni) da mac funziona, da pc no.

Io temo sia perchè, in realtà, il pcm proveniente da mac viene interpretato come AIF e non WAV, per quets mi piacerebbe qualche conferma o smentita da altri ambienti.

Il fatto che a standard, esca mediante FLAC --force-raw-format (e funzioni) mi sembra significativo.

Salvo diverse indicazioni, per il momento direi che la strada da battere è quella di uscire in FLAC e lasciare (almeno) la conversione a Squeezelite, dopo l'upsampling, anche se a me pare un'inutile spreco di risorse.

Io porvo questa, se qualcuno ha riscontri o idee diverse ci aggiorniamo.

[marcoc1712]

Salvo diverse indicazioni, per il momento direi che la strada da battere è quella di uscire in FLAC e lasciare (almeno) la conversione a Squeezelite, dopo l'upsampling, anche se a me pare un'inutile spreco di risorse.

Scusate, sto scrivendo da una posizione impossibile, intanto posto poi elaboro.

Queste sono le righe da metter in custom-covert.conf per fare upsampling passando SEMPRE da FLAC.

Provato e funzionante su mac, Dac Passion per favore prova.

flc flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S

aif flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S


wav flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S

In tipi file bisogna scegliere flac flac/sox, aif flac/sox , wav flac/sox, il resto disabilitato.

Immagino sia possibile usare solo sox, ma questo provoca un glitch all'inizio del brano, passare per Flac lo evita, oltre ad abilitare le ricerche veloci.

Ad oggi è il meglio cheio riesca a fare, almeno su mac.

[antonellocaroli]

Scusate, sto scrivendo da una posizione impossibile, intanto posto poi elaboro.

Queste sono le righe da metter in custom-covert.conf per fare upsampling passando SEMPRE da FLAC.

Provato e funzionante su mac, Dac Passion per favore prova.

flc flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S

aif flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S


wav flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S

In tipi file bisogna scegliere flac flac/sox, aif flac/sox , wav flac/sox, il resto disabilitato.

Immagino sia possibile usare solo sox, ma questo provoca un glitch all'inizio del brano, passare per Flac lo evita, oltre ad abilitare le ricerche veloci.

Ad oggi è il meglio cheio riesca a fare, almeno su mac.

Qui siamo tornati all´inizio peró

[marcoc1712]

Perchè? non credo proprio:

1. L'upsampling è finalmente e certamente sul server (quello che dacPassion non riusciva a fare), solo la conversione è sul renderer, cosa che non mi piace perchè avvenendo (anche) dopo l'upsampling è uno spreco di risorse.

2. Secondo me dove funziona correttamente la comunicazione tra LMS e squeezelite con WAV (ma bisogna provare con files costruiti offline per limitare le variabili e verificare nei log di squeezelite) vanno bene anche il metodo che ho proposto e che Paolo ha corretto, ma rimane il beneficio del dubbio fino a che non si trova una configurazione sicuramente funzionante.

3.Molti dei comandi che ho visto girare alla prova del fuoco si sono rivelato sbagliati, parevano dare il risultato cercato perchè semplicemente funzionavano a metà... Per forza erano anche molto leggeri, peccato non facesso upsampling per nulla.

Non è finita qui, se capiamo il problema con wav, possiamo certamente ottimizzare le cose (aspettiamo la risposta di Michael), ma adesso disponiamo di un modo certamente funzionante e misurabile, eventualmente da confrontare (per consumo di risorse e qualità sonora) con l'upsampling su squeezelite.

Sarebbe interessante capire come fanno altri sistemi (es. HQP) alle prese con l'upsamling: passano sempre da Flac?

Io ho capito (meglio) una cosa: Ci sarebbe bisogno come il pane di un sistema per gestire 'facilmente' questo genere di cose in LMS, ma è talmente incasinato che capisco perchè se ne tengono tutti così ben lontani...

Ah, ovviamente, tu devi aggiungere IR ad FT per gli stream remoti in flc flc * *.

[DacPassion]

Scusate, sto scrivendo da una posizione impossibile, intanto posto poi elaboro.

Queste sono le righe da metter in custom-covert.conf per fare upsampling passando SEMPRE da FLAC.

Provato e funzionante su mac, Dac Passion per favore prova.

flc flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S

aif flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S


wav flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 192000 dither -S

In tipi file bisogna scegliere flac flac/sox, aif flac/sox , wav flac/sox, il resto disabilitato.

Immagino sia possibile usare solo sox, ma questo provoca un glitch all'inizio del brano, passare per Flac lo evita, oltre ad abilitare le ricerche veloci.

Ad oggi è il meglio cheio riesca a fare, almeno su mac.

Grazie per tutto l'impegno che ci stai mettendo!!! Ho copiato quanto sopra nel file custom-convert.conf

La musica esce ..ma addirittura in pcm e tutto quello che mi dici di selezionare in tipi di flac mi risulta impossibile. Provato più volte, ho anche riavviato la macchina!





...mi sto scoraggiando

[marcoc1712]

Grazie per tutto l'impegno che ci stai mettendo!!! Ho copiato quanto sopra nel file custom-convert.conf

La musica esce ..ma addirittura in pcm e tutto quello che mi dici di selezionare in tipi di flac mi risulta impossibile. Provato più volte, ho anche riavviato la macchina!





...mi sto scoraggiando

Hai riavviato il server, vero?

[DacPassion]

Hai riavviato il server, vero?

Ho riavviato anche il mac per sicurezza

[UnixMan]

Tutto giusto, tranne che per il -r, puoi dare anche le opzioni di rate, ma devi curare tu che -r ed il rate siano congruenti. Se esci raw sei obbligato.

quando si usa "raw" in ingresso è (ovviamente) necessario specificare tutti i dettagli del formato desiderato, altrimenti SOX non avrebbe alcun modo per capire come interpretare i dati in ingresso.

Lo stesso NON è vero in uscita, però: in tal caso SOX può utilizzare i default, per cui alcuni parametri (in particolare, nel nostro caso, il sample rate) possono essere omessi.

Va da sé che, ovviamente, per quanto riguarda il s/r in uscita il default utilizzato è quello più ragionevole, cioè quello dello stream "interno" prima della conversione finale. Se applichiamo la funzione "rate" è evidente che -se non diversamente richiesto- (il che sarebbe ovviamente un errore, che comporterebbe un ulteriore resampling) lo stream in uscita avrà lo stesso s/r che abbiamo chiesto alla funzione "rate", ed è quindi superfluo (e foriero di errori) specificarlo anche nella definizione dello stream di uscita.

Ad es.:

$ sox -V3  Linn_01.flac  -t raw -b 24  pippo.pcm  gain -6 rate -v -b 90 -a 192000 dither -s
sox:      SoX v14.4.1
sox INFO formats: detected file format type `flac'

Input File     : 'Linn_01.flac'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:10.24 = 8389584 samples = 14268 CDDA sectors
File Size      : 14.0M
Bit Rate       : 590k
Sample Encoding: 16-bit FLAC
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comments       : 
TRACKNUMBER=1
title=String Quartet No. 16 in F Major: II. from The Complete String Quartets Vol.2
artist=Belcea Quartet
album=String Quartet No. 16 in F Major, Op. 135: II. Vivace
genre=Classical
Date=2013
composer=Ludwig van Beethoven
ALBUMARTIST=Belcea Quartet

Output File    : 'pippo.pcm' (raw)
Channels       : 2
Sample Rate    : 192000
Precision      : 24-bit
Duration       : 00:03:10.24 = 36526080 samples ~ 14268 CDDA sectors
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comments       : 
TRACKNUMBER=1
title=String Quartet No. 16 in F Major: II. from The Complete String Quartets Vol.2
artist=Belcea Quartet
album=String Quartet No. 16 in F Major, Op. 135: II. Vivace
genre=Classical
Date=2013
composer=Ludwig van Beethoven
ALBUMARTIST=Belcea Quartet

sox WARN dither: no `shibata' filter is available for rate 192000; using sloped TPDF
sox INFO sox: effects chain: input        44100Hz  2 channels
sox INFO sox: effects chain: gain         44100Hz  2 channels
sox INFO sox: effects chain: rate        192000Hz  2 channels
sox INFO sox: effects chain: dither      192000Hz  2 channels
sox INFO sox: effects chain: output      192000Hz  2 channels

Notare come l'opzione "-V3" mostri in dettaglio la catena dei diversi processi:

conversione di ingresso,
riduzione del guadagno(*),
resampling(*),
dithering(*),
conversione di uscita.

(*) come richiesto da riga di comando, nell'esatto ordine specificato.


Tanto per curiosità, ecco cosa succede se chiedo un resamplig ad un dato s/r ma poi specifico un formato di uscita con un s/r diverso:

$ sox -V3 Linn_01.flac -t raw -b 24 -r 96000 pippo.pcm gain -6 rate -v -b 90 -a 192000 dither                                                 sox:      SoX v14.4.1
sox INFO formats: detected file format type `flac'

Input File     : 'Linn_01.flac'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:10.24 = 8389584 samples = 14268 CDDA sectors
File Size      : 14.0M
Bit Rate       : 590k
Sample Encoding: 16-bit FLAC
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comments       : 
TRACKNUMBER=1
title=String Quartet No. 16 in F Major: II. from The Complete String Quartets Vol.2
artist=Belcea Quartet
album=String Quartet No. 16 in F Major, Op. 135: II. Vivace
genre=Classical
Date=2013
composer=Ludwig van Beethoven
ALBUMARTIST=Belcea Quartet


Output File    : 'pippo.pcm' (raw)
Channels       : 2
Sample Rate    : 96000
Precision      : 24-bit
Duration       : 00:03:10.24 = 18263040 samples ~ 14268 CDDA sectors
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comments       : 
TRACKNUMBER=1
title=String Quartet No. 16 in F Major: II. from The Complete String Quartets Vol.2
artist=Belcea Quartet
album=String Quartet No. 16 in F Major, Op. 135: II. Vivace
genre=Classical
Date=2013
composer=Ludwig van Beethoven
ALBUMARTIST=Belcea Quartet

sox INFO sox: effects chain: input        44100Hz  2 channels
sox INFO sox: effects chain: gain         44100Hz  2 channels
sox INFO sox: effects chain: rate        192000Hz  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

Ovviamente, la funzione "rate" viene chiamata DUE volte. La prima da me, con i parametri che ho richiesto, mentre la seconda è chiamata automaticamente dalla conversione di uscita.

Da notare (anche se da questo output non si può vedere) che questa seconda chiamata a "rate" NON usa i parametri richiesti per la prima chiamata (quella "esplicita"), ma quelli di default.

Da notare inoltre come la funzione "dither" in questo caso è gestita in modo speciale: anziché essere chiamata nell'ordine specificato dalla riga di comando (dopo il primo "rate", quello "esplicito"), è chiamata come ultima funzione della catena, come è giusto che sia.

N.B.: questo non accade se "dither" non viene indicato come ultimo comando della catena "esplicita". SOX cioè è "furbo", ma non "prepotente" (e limitante). Evita di fare stupidaggini di suo ma, se per qualche strano motivo l'utente vuole aggiungere il dither prima di fare qualche altra operazione, sox non gli impedisce di farlo.

In altre parole, come ogni comando Unix che si rispetti, anche sox non pone limiti né restrizioni a ciò che l'utente gli dice di fare. Neanche per impedirgli di fare ca%%ate:

“UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.”