upsampling (universo LMS/Squeezelite/Squeezeplay) | Stampa

Quote:

---

Originariamente inviato da bigtube

Paolo hai qualche suggerimento per integrarle o variarle?

---

niente di "preconfezionato". Anche perché, IME, le impostazioni "ottimali" (cioè, quelle che "suonano" meglio all'ascolto) variano sensibilmente da un sistema all'altro, soprattutto con DAC diversi. Quindi non puoi fare altro che sperimentare ed ascoltare, in prima persona, sul tuo stesso sistema.

Per assurdo che possa sembrare (a me per primo...), in almeno un caso mi è capitato che l'impostazione che all'ascolto suonava meglio era quella peggiore in assoluto, teoricamente del tutto inaccettabile: resampling con algoritmo "Zero Order Hold"! :oooo

(su altri sistemi quella stessa impostazione risulta invece semplicemente inascoltabile, come ci si aspetterebbe che debba essere sempre).

Per prima cosa proverei con l'impostazione più semplice, cioè banalmente con "rate -v" (che dovrebbe essere equivalente a quanto fatto da squeezelite con libsoxr con l'impostazione "VHQ").

Dopo di che puoi provare a giocare con il "tipo" di filtro, cioè con la risposta in fase. Che determina "qualità" e quantità di pre- e/o post- ringing della risposta all'impulso nel dominio del tempo. Questo lo puoi fare aggiungendo l'opzione "-M" oppure "-I".

(il filtro a fase lineare - opzione "-L" - è quello usato di default, quindi specificare tale opzione dovrebbe essere del tutto superfluo).

In alternativa alle opzioni -M/-I/-L puoi usare l'opzione "-p x", con "x" che è un numero compreso tra 0 e 100:

• "-p 0", equivalente a "-M" (filtro a fase minima)
• "-p 25", equivalente a "-I"
• "-p 50", equivalente a "-L" (filtro a fase lineare, default)

Come è ovvio la "-p" è una opzione molto potente e versatile, che consente di ottenere qualsiasi risposta "intermedia" nonché di andare anche "oltre" la risposta lineare, fino ad una risposta "maximum phase" ("-p 100").

Puoi inoltre provare ad aggiungere "-a" e "-s", in varie combinazioni con le altre opzioni. Queste due opzioni in sostanza determinano (indirettamente) la "pendenza" (ordine) del filtro impiegato:

• "-a" indica di permettere una non completa soppressione degli "alias" al di sopra della banda passante (e quindi, a parità di banda passante, l'uso di un filtro con pendenza minore); come "side-effect" implica tra l'altro un minore utilizzo della CPU.
  
• "-s" indica di utilizzare un filtro "steep", ad alta pendenza, per ottenere una banda passante del 99% (*)

Infine puoi giocare con l'opzione "-b x", dove "x" è un numero compreso tra 74 e 99.7. Questo determina la "banda passante" del resampler, intesa come percentuale della banda passante del segnale di ingresso riprodotta in uscita. (*)

Va da sé che all'aumento della banda passante richiesta corrisponde necessariamente anche l'uso di filtri con pendenza maggiore, quindi tipicamente risposte all'impulso più "lunghe", con più pre- e/o -post ringing, nonché un maggiore consumo di risorse di CPU.

Considerando che in genere all'ascolto "suonano meglio" i filtri meno ripidi, IMHO è preferibile sacrificare un po' di banda passante (anche scendendo al disotto del 95% di default dell'opzione "-v") piuttosto che cercare di rincorrere l'ultimo hertz...

(*) sì, la banda passante dopo il resampling è sempre inferiore a quella in ingresso, cioè il resampling "taglia" (ancora di più di quanto già non lo fossero...) le frequenze più alte. Cioè, a dispetto della frequenza di campionamento più alta, il segnale "upsamplato" ha una banda passante effettiva (leggermente) minore di quello originale! :oooo

N.B.: Questo NON è un limite di SOX e dei suoi algoritmi ma una caratteristica fisico/matematica inevitabile del processo stesso di resampling, comunque realizzato!

P.S.: quanto sopra è semplicemente una traduzione/spiegazione di quanto chiaramente illustrato nella man page di sox:

codice:

---

[...]
rate [-q|-l|-m|-h|-v] [override-options] RATE[k]
      Change  the  audio  sampling  rate (i.e. resample the audio) to any given RATE (even non-integer if this is supported by the
      output file format) using a quality level defined as follows:

                                                  Quality  Band-  Rej dB  Typical Use
                                                            width
                                            -q    quick    n/a    ~=30 @  playback on
                                                                    Fs/4    ancient hardware
                                            -l      low      80%    100    playback on old
                                                                            hardware
                                            -m    medium    95%    100    audio playback
                                            -h    high      95%    125    16-bit mastering
                                                                            (use with dither)
                                            -v  very high  95%    175    24-bit mastering

      where Band-width is the percentage of the audio frequency band that is preserved and Rej dB is the level of noise rejection.
      Increasing levels of resampling quality come at the expense of increasing amounts of time to process the audio.  If no qual-
      ity option is given, the quality level used is `high' (but see `Playing & Recording Audio' above regarding playback).

      The  `quick' algorithm uses cubic interpolation; all others use band-limited interpolation.  By default, all algorithms have
      a `linear' phase response; for `medium', `high' and `very high', the phase response is configurable (see below).
      [...]
      The  simple  quality  selection  described above provides settings that satisfy the needs of the vast majority of resampling
      tasks.  Occasionally, however, it may be desirable to fine-tune the resampler's filter response; this can be achieved  using
      override options, as detailed in the following table:

                                    -M/-I/-L    Phase response = minimum/intermediate/linear
                                    -s          Steep filter (band-width = 99%)
                                    -a          Allow aliasing/imaging above the pass-band
                                    -b 74-99.7  Any band-width %
                                    -p 0-100    Any phase response (0 = minimum, 25 = intermediate,
                                                50 = linear, 100 = maximum)
[...]

---

Sto facendo la prova di upsampling con LMS su osx, ho editato il file convert.conf ho cancellato tutto quello che c'era e ho messo questo:

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

nella macchina con daphile ho disabilitato il file server e nelle opzioni di upsampling ho messo only if native rate not supported

In questa maniera LMS sul Mac si occupa dell'upsampling a 192khz dei file e la macchina con daphile si occupa solo di "passare" la musica al dac va bene?

Nella macchina con Daphile ho un consumo di risorse maggiore rispetto a quando l'upsampling lo facevo fare a squeezelite in locale, perché?

Quote:

---

Originariamente inviato da DacPassion

ho editato il file convert.conf ho cancellato tutto quello che c'era e ho messo questo:

---

ehm... quello che hai fatto lo perderai al primo aggiornamento.... Il modo corretto è creare un file custom-convert.conf nella home di slimserver (dipende da come hai fatto l'installazione).

Quote:

---

Originariamente inviato da DacPassion

Nella macchina con Daphile ho un consumo di risorse maggiore rispetto a quando l'upsampling lo facevo fare a squeezelite in locale, perché?

---

Secondo me per due cause distinte:

a. A mio avviso con -t wav - -t flac stai forzando la conversione in flac sul server, quindi daphile (squeezelite) deve fare anche l'inverso (cioè flac -> PCM) su uno stream a 192K, quindi almeno 4x più oneroso della situazione precedente, dove la conversione avveniva al formato 'nativo' (44.1?).

b. Selezionado l'opzione di resampling solo su eccezione, SL fa il resampling SE la frequenza non è disponibile, sei sicuro di aver messo -r 192000 ? In caso contrario anche squeezelite fa resampling, da evitare!

Potrei sbagliarmi ed interpretare male il comando di sox, ma mi sembra proprio sia così, se posti il comando di squeezelite vediamo.

Comunque, nei vari log di LMS e squeezelite trovi i dettagli di tutto quello che viene fatto.

Edit ho visto che hai risposto mentre scrivevo.

Quindi se volessi fare l'inverso convertire da flac a pcm sul server (la cosa più giusta da fare o ho capito male?) come devo cambiare quella stringa? Inverto di posizione flac e pcm?

Su squeezelite non posso controllare molto (credo) lo sto usando da Daphile

Ho fatto così:
https://up.nexthardware.com/user_ima...ge/image59.jpg

Quote:

---

Originariamente inviato da DacPassion

Toglietemi una curiosità, sto conducendo proprio ora una prova (molto più terra terra delle vostre) per vedere la differenza di consumo risorse tra queste due situazioni:

A: Mac con osx 10.10.2 con LMS 7.9 + Futro s450 con daphile ultima beta (disabilitato LMS) con squeezelite che fa upsampling di un file 16/44 a 192

B: Futro s450 con daphile ultima beta utilizzato in modo "tradizionale" con upsampling fatto da squeezelite da 16/44 a 192

ovviamente il consumo di risorse nella situazione A è minore della situazione B e fin qui non ci piove. Una cosa che ho notato è che nella situazione B squeezelite è praticamente quasi sempre attivo (è quasi sempre presenti tra i processi) invece nella situazione A squeezelite appare tra i processi per qualche secondo e poi scompare per lungo tempo per poi ricomarire, come mai??

---

Diverse possibilità:

1. C'è un'opzione che informa squeezelite, quando opera come local player (come in daphile) di accedere direttamente ai file, in questo modo LMS passa solo l'URI del file che viene poi gestito da squeezelite. Verifica sia deselezionato se vuoi escluderlo a fini di prova, ma ha senso sia attivo, se non fai fare resamplibg/decoding al server.

2. Se il server passa FLAC a daphile, questo deve fare la conversione, quindi maggiore attività (pur se minima) rispetto alla situazione in cui riceve già uno stream PCM.

3. Dipende da come sono configurati i buffer in uscita, buffer grandi -> attività più intensa per brevi periodi, buffer piccoli -> attività più continua, verifica siano impostati sugli stessi valori.

Esistono teorie per cui il 'profilo' di attività ha potenziali effetti sulla qualità del suono, analogamente al play from ram, per intendersi.

Secondo alcuni larghi buffer, fino al limite del completo caricamento in ram del pezzo, ha effetti più evidenti nel breve periodo di attività iniziale, ma poi praticamente nulli per il resto della riproduzione, mentre un profilo più continuo, offenuto con buffer minimi, genera un 'tappeto' costante di rumore minimo. Si tratta di scegliere caso per caso tra i due mali, il consiglio è di evitare situazioni intermedie, con brevi momenti di attività intensa e altrettando brevi momenti di idle.

Quote:

---

Originariamente inviato da DacPassion

Quindi se volessi fare l'inverso convertire da flac a pcm sul server (la cosa più giusta da fare o ho capito male?) come devo cambiare quella stringa?

---

Posto che dovresti PRIMA ripristinare la situazione precedente del convert.conf, dovretsi poi andare in impostazioni -> Avanzate -> tipi di File ed alla voce FLAC dovresti impostare:

AIFF disattivato
FLAC disattivato
MP3 disattivato (se accessibile, cioè se hai lame sul pc)
PCM flac

ATTENZIONE: la chiave è l'ultimo valore PCM flac, in qualche versione di LMS invece di flac puoi selezionare sox.

In questo modo, senza aggiungere altro in custom-covert.conf, tutti ifile flac vengono convertiti in PCM prima di essere inviati.

In custom-convert.conf, toglierei almeno la forzatura di conversione (-t wav - -t flac), ma bada bene, devi partire dalla copia di convert.conf e li aggiungere i comandi relativi.

Lo so che è brigoso...

Puoi anche provare a sostituire questo (è il mio convert.conf):

flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$

ed aggiungere le opzioni di resamplig.

Es.

| [sox] -D -q -b 24 - rate -v -b 98 -L -a 192000

da verificare.

Quote:

---

Originariamente inviato da DacPassion

Su squeezelite non posso controllare molto (credo) lo sto usando da Daphile

Ho fatto così:
https://up.nexthardware.com/user_ima...ge/image59.jpg

---

Va bene, se gli arriva 192 non fa resampling. Il buffer in uscita è 256 MB, a 192/32 sono circa 90 sec di riproduzione.

Quote:

---

Originariamente inviato da Crixx

Tra l'altro ho letto che sox è in grado di fare anche da convolutore, sarebbe interessante implementare il tutto con un singolo comando.

---

Guarda qui spiega come usare SOX in LMS per applicare sia FIR che i parametri di equalizzazione generati con REW.

Bisognerebbe provare, ma se consente di usare FIR per le frequenze fino a, diciamo 300 Hz ed un numero sufficiente di parametri di equalizzazione per le ferquenze superiori, potrebbe essere una soluzione elegante, efficiente e (potenzialmente) meno intrusiva di un convolver vero e proprio, ideale per correzioni 'leggere', come rifinitura.

Sconsigliato solo a chi sente il bisogno irrefrenabile di estrarre l'aspersorio sentendo il termine equalizzatore...

Quote:

---

# $Id$
#
# Configuration file for transcoding
#
# If you wish to create custom transcoding entries that won't be overwritten
# by a new release of Logitech Media Server, create a custom-convert.conf file in the
# Logitech Media Server root directory, or the root of the Plugins directory.
#
# On Debian, you can also create this file in # /etc/slimserver/custom-convert.conf
#
# first line is the source format, destination format and the destination device. Asterisk matches all
# second line is the command line for the conversion
#
# First line format:
#
#
# : Source music format: mp3, mp4, ogg, wav, etc...
# : Destination music format: Generally mp3, or
# possibly aif or others depending on the types
# your player supports. SliMP3 supports only
# MP3. Squeezebox currently supports mp3, aif
# and pcm. Squeezebox2 adds support for Flac and WMA.
# : currently slimp3, squeezebox, or *.
# The * is a wildcard that matches all device
# types.
# : The ID of the destination device. The
# ID of the destination device is the MAC address
# of a SliMP3 or Squeezebox device, or the IP of
# an HTTP client (such as your computer running
# WinAmp). The '*' wildcard matches all hosts
#
# either or both of and
# may be the '*' wildcard
#
#
# $FILE$ is the absolute path to the local source file
# $URL$ is the full URL for remote streams
# [bin] is the executable binary for the encoder or decoder
# - is a special command line that implies passthrough of data
#
# Capabilities
# I - can transcode from stdin
# F - can transcode from a named file
# R - can transcode from a remote URL (URL types unspecified)
#
# O - can seek to a byte offset in the source stream (not yet implemented)
# T - can seek to a start time offset
# U - can seek to start time offset and finish at end time offset
#
# D - can downsample
# B - can limit bitrate
#
# default is "IF"
#
# Substitution strings for variable capabilities
# %f, $FILE$ - file path (local files)
# %F, $URL$ - full URL (remote streams)
#
# %o - stream start byte offset
#
# %S - stream samples start offset (not yet implemented)
# %s - stream seconds start offset
# %t - stream time (m:ss) start offset
# %U - stream samples end offset (not yet implemented)
# %u - stream seconds end offset
# %v - stream time (m:ss) end offset
# %w - stream seconds duration
#
# %b - limit bitrate: b/s
# %B - limit bitrate: kb/s
# %d - samplerate: samples/s
# %D - samplerate: ksamples/s

# %C, $CHANNELS$ - channel count
# %c, $OCHANNELS$ - output channel count
# %i - clientid
# %I, $CLIENTID$ - clientid ( : or . replaced by - )
# %p - player model
# %P, $PLAYER$ - player model ( SPACE or QOUTE replaced by _ )
# %n - player name
# %N, $NAME$ - player name ( SPACE or QOUTE replaced by _ )
# %q, $QUALITY$ - quality
# %Q, - quality ( fractal notation: if = '0' return '01' )
# ${FILENAME}$ - contents of {FILENAME} (may contain other $*$ substitutions )

# specific combinations match before wildcards

mp4 mp3 * *
# FB:{BITRATE=--abr %B}T:{START=-j %s}U:{END=-e %u}
[faad] -q -w -f 1 $START$ $END$ $FILE$ | [lame] --silent -q $QUALITY$ $BITRATE$ - -

aac mp3 * *
# IFB:{BITRATE=--abr %B}
[faad] -q -w -f 1 $FILE$ | [lame] --silent -q $QUALITY$ $BITRATE$ - -

sls mp3 * *
# FB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[sls] $FILE$ - -s | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

alc mp3 * *
# FB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}T:{START=-j %s}U:{END=-e %u}
[faad] -q -w -f 1 $START$ $END$ $FILE$ | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

ogg mp3 * *
# IFB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[sox] -q -t ogg $FILE$ -t wav - | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

wav mp3 * *
# IFB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ $FILE$ -

aif mp3 * *
# IFB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ $FILE$ -

flc mp3 * *
# FB:{BITRATE=--abr %B}T:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=--resample %D}
[flac] -dcs $START$ $END$ -- $FILE$ | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

wma mp3 * *
# F:{PATH=%f}R:{PATH=%F}B:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[wmadec] -w $PATH$ | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

wmal mp3 * *
# F:{PATH=%f}R:{PATH=%F}B:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[wmadec] -w $PATH$ | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

wmap mp3 * *
# F:{PATH=%f}R:{PATH=%F}B:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[wmadec] -w $PATH$ | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

mpc mp3 * *
# IRB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[mppdec] --silent --prev --gain 3 - - | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

ape mp3 * *
# FB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[mac] $FILE$ - -d | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

wvp mp3 * *
# FB:{BITRATE=--abr %B}T:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=--resample %D}
[wvunpack] $FILE$ -wq $START$ $END$ -o - | [lame] --silent -q $QUALITY$ $RESAMPLE$ $BITRATE$ - -

mp3 mp3 * *
-

# Non-mp3 starts here
aif aif * *
-

wav pcm * *
-

flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$

flc aif * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs --force-raw-format --endian=big --sign=signed $START$ $END$ -- $FILE$

ogf ogf * *
-

ogf flc * *
[flac] --ogg -dcs -- $FILE$ | [flac] -cs --ignore-chunk-sizes --totally-silent --compression-level-0 -

ogg ogg * *
-

ogg aif * *
[sox] -q -t ogg $FILE$ -t raw -r 44100 -c 2 -2 -s $-x$ -

ogg pcm * *
[sox] -q -t ogg $FILE$ -t raw -r 44100 -c 2 -2 -s -

wma pcm * *
# F:{PATH=%f}R:{PATH=%F}
[wmadec] -r 44100 -b 16 -n 2 $PATH$

wmal pcm * *
# F:{PATH=%f}R:{PATH=%F}
[wmadec] -r 44100 -b 16 -n 2 $PATH$

wmap pcm * *
# F:{PATH=%f}R:{PATH=%F}
[wmadec] -r 44100 -b 16 -n 2 $PATH$

mpc pcm * *
# IR
[mppdec] --raw-le --silent --prev --gain 2 - -

ape pcm * *
# F
[mac] $FILE$ - -d

mpc aif * *
# IR
[mppdec] --raw-be --silent --prev --gain 2 - -

alc pcm * *
# FT:{START=-j %s}U:{END=-e %u}
[faad] -q -w -f 2 $START$ $END$ $FILE$

wvp pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[wvunpack] $FILE$ -rq $START$ $END$ -o -

mp4 pcm * *
# FT:{START=-j %s}U:{END=-e %u}
[faad] -q -w -f 2 -b 1 $START$ $END$ $FILE$

aac pcm * *
# IF
[faad] -q -w -f 2 -b 1 $FILE$

sls pcm * *
# F
[sls] $FILE$ - -r -s

wma wma * *
-

wmal wmal * *
-

wmap wmap * *
-

# FLAC output starts here

#mp3 flc * *
# [lame] --mp3input --decode -t --silent $FILE$ - | [flac] -cs --totally-silent --compression-level-0 -

flc flc * *
-

aif flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ -

wav flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ -

ogg flc * *
# IFRD:{RESAMPLE=-r %d}
[sox] -t ogg $FILE$ -t flac -C 0 $RESAMPLE$ -

wma flc * *
# F:{PATH=%f}R:{PATH=%F}
[wmadec] -w $PATH$ | [flac] -cs --totally-silent --compression-level-0 -

wmal flc * *
# F:{PATH=%f}R:{PATH=%F}
[wmadec] -w $PATH$ | [flac] -cs --totally-silent --compression-level-0 -

wmap flc * *
# F:{PATH=%f}R:{PATH=%F}
[wmadec] -w $PATH$ | [flac] -cs --totally-silent --compression-level-0 -

mpc flc * *
# IR
[mppdec] --silent --prev --gain 2 - - | [flac] -cs --totally-silent --compression-level-0 -

ape flc * *
# F
[mac] $FILE$ - -d | [flac] -cs --totally-silent --compression-level-0 -

mp4 flc * *
# FT:{START=-j %s}U:{END=-e %u}
[faad] -q -w -f 1 $START$ $END$ $FILE$ | [flac] -cs --totally-silent --compression-level-0 --ignore-chunk-sizes -

aac flc * *
# IF
[faad] -q -w -f 1 $FILE$ | [flac] -cs --totally-silent --compression-level-0 --ignore-chunk-sizes -

sls flc * *
# FD:{RESAMPLE=-r %d}
[sls] $FILE$ - -s | [sox] -q -t wav - -t flac -C 0 $RESAMPLE$ -

alc flc * *
# FT:{START=-j %s}U:{END=-e %u}D:{RESAMPLE=-r %d}
[faad] -q -w -f 1 $START$ $END$ $FILE$ | [sox] -q -t wav - -t flac -C 0 $RESAMPLE$ -

wvp flc * *
# FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
[wvunpack] $FILE$ -wq $START$ $END$ -o - | [sox] -q -t wav - -t flac -C 0 $RESAMPLE$ -

# AAC & ALAC output start here

aac aac * *
-

mp4 aac * *
-

sls aac * *
-

alc alc * *
-

# special case for smart bitrates on mp3 input
mp3 mp3 transcode *
# IFB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[lame] --silent -q $QUALITY$ $BITRATE$ $RESAMPLE$ --mp3input $FILE$ -

flc flc transcode *
# FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -C 0 $RESAMPLE$ -

# This example transcodes MP3s to MP3s, if the target machine has the
# given MAC address. This rule will take precedence over the
# previous rule because it's more specific.
#mp3 mp3 squeezebox 00:02:dd:34:e9:62
# ./brute_filter $FILE$ -

spdr spdr * *
-

dsf dsf * *
# IFD
-

dff dff * *
# IFD
-

---

Questo é il file convert.conf originale...;)

Le recenti esperienze e la curiosità di alcuni di voi (grazie, DacPassion) mi hanno fatto fare 'mente locale' su alcune questioni relative all'upsampling/conversione su LMS vs squeezelite.

Come sapete, la mia opinione è di cercare di minimizzare all'estremo l'impronta termica (e con essa il rumore) del 'device' anteposto al DAC con funzioni di renderer, mentre considero praticamente ininfluente (se ben realizzata) l'infrastruttura di rete, dove con 'device' intendo il PC, SOC, NUC, SB o quello che volete, fino all'estremo limite di non avere proprio nessun device, cioè semplicemente un'interfaccia (che comunque comprende un microprocessore) collegata in i2s al DAC, praticamente uno Squeezebox redivivo. A brevissimo avremo diverse opzioni tra cui scegliere.

So che esistono opinioni diverse, poco male, chi crede di poter migliorare 'investendo' su server e rete lo faccia pure, non inficia in nessun modo l'approccio di cui sopra.

L'unico approccio incompatibile è quello di 'carozzare' il 'device' rederer, tipicamente un PC, al fine di consentire l'adozione di misure di contrasto al rumore rivelatesi efficaci in architetture stand alone come il cmp2.

Si tratta di scommettere che il 'saldo' tra il rumore prodotto da un renderer minimo e quello risultante da uno carozzato ma attrezzato di contromuisure adeguate sia positivo a favore di quest'ultimo.

Credo sia molto difficile, se non impossibile. Aggiungere per togliere non è quasi mai una buona pratica, mentre quello che non c'è non può far male.

Però...

Bisogna essere coerenti con il principio fino in fondo.

Al DAC arriva uno stream in formato PCM nella risoluzione (frequenza di campionamento e profondità in bit) selezionata, ipotizziamo per comodità 352800/32, ma potrebbe essere qualsiasi altra, partendo da un file su disco in un formato ed in una risoluzione potenzialmente differente, ipotizziamo FLAC 44100/16.

Per far si che il file venga convertito nello stream adatto al DAC occorre che venga efettuata:

a. conversione di formato da FLAC a PCM.
b. upsampling.

Ora, l'ordine in cui avvengono le due operazioni NON E' ININFLUENTE: convertire PRIMA dell'upsampling è molto più economico, in termini di risorse, che non farlo a valle: 16 volte tanto.

In un'architettura distribuita, come quelle di cui stiamo parlando, la scelta di utilizzare FLAC invece di WAV (PCM) è giustificata, oltre che per il minor uso di storage, soprattutto per il minor impiego di banda in trasmissione, a fronte di un 'leggero' appesantimento delle attività del renderer (posto ne sia capace).

A parte il fatto che proprio così leggero non è e su 'vecchi' microprocessori come quelli sullo SB3 aveva il suo effetto, il ragionamento regge SE non si fa nemmeno upsampling, dato che il risparmio di banda usando un flac rispetto ad un wav e circa del 30%, mentre l'upsampling porta ad un consumo maggiore del 1500%.

Quindi, la pratica di inviare FLAC dopo l'upsampling al renderer a mio avviso è controproducente perchè:

a. Occupa 16 volte la banda necessaria a trasferire il formato originario.
b. Impiega le risorse del rendere 16 volte di più rispetto alla conversione del file originario.

La semplice attenzione di convertire PRIMA di inviare non risolve il problema di banda (anzi lo peggiora del 30% circa), ma praticamente azzera le necessità di calcolo del renderer, consentendo la sua configurazione minima.

Però...

Posto che la scelta del renderer deve a mio avviso essere fatta in ottica minimalista, con il minimo di compromessi qualitativi possibili, attualmente la scelta cade probabilmente su SOC/NUC o mini pc con capacità elaborative significative:

Le prove di DacPassion hanno evidenziato che il resampling sul suo fultro aggiunge il 2% di lavoro di CPU, sempre sotto il 10%

In queste condizioni, quando il Renderer è già stato scelto e sarebbe comunque lì, credo che il 2% di lavoro di CPU in più sposti poco in termini di rumore generato, mentre cambia di parecchio l'occupazione di banda, consentendo al server di inviare nel formato orginario e quindi convertire e fare upsampling in locale.

La banda può essere più o meno importante, dipendentemente dalla configurazione di rete, ma io non sarei così certo che un intenso lavoro dell'interfaccia di rete (16x) e di tutto quanto ne consegue nel renderer sia preferibile in termini di rumore, rispetto ad un 2% di CPU.

Bisognerebbe verificare e misurare e qui lascio il campo ad altri, certo che per molti (me compreso) attrezzarsi per una banda disponibile 16 volte l'attuale sarebbe difficile ed imporrebbe compromessi, almeno in questi casi mi sembra un'opzione da non sottovalutare.

Sarebbe interessante che chi è attrezzato per farlo postasse le sue impressioni a confronto nelle due diverse configurazioni.

Cosa ne dite?