Marco ancora non ho fatto prove serie...ma a primo acchito mi sembra che saltare il router porti dei benefici....
Printable View
NO, non lo so, nel senso che non l'ho mai provato, ma puoi provare a partre da qui:
mp3 mp3 * *
# IFB:{BITRATE=--abr %B}D:{RESAMPLE=--resample %D}
[lame] --silent -q $QUALITY$ $BITRATE$ $RESAMPLE$ --mp3input $FILE$ -
oppure
mp3 flc * *
# IF
[lame] --mp3input --decode -t --silent $FILE$ - | [flac] -cs --totally-silent --compression-level-0 -
impostando mp3 mp3 disabled e mp3 flac flac in ipi file (o lame/flac, probabilmente).
Bisogna provarli.
Oltretutto, se hai i files su un NAS, lo stesso lo devi fare per dare accesso al NAS, quando non fai trascodifica sul server.
In merito a tutto l'argomento... Ogni tanto si ripresenta sotto forme diverse. Ci sono situazioni in cui la rete di mezzo crea problemi (Rasperry PI), così come lo crea l'utilizzo di usb per il disco e per il DAC, ma questo non significa sia sempre così, come non lo significa per USB...
Segmentare 'a ragion veduta' le reti è una buona pratica, ma che la semplice interposizione di un (buon e sano) router inserisca rumore... dubito, comunque provare è semplice, puoi inserire il router anche nella seconda rete e vedi cosa succede.
Non stiamo parlando di uno di quei routers 'tipo' telecom con T10/100 scarsa, che hanno un throughput reale <50 Mbit/sec, pensati per ADSL e WIFI usato per file upsamplati a 384/32, magari 'appoggiato' sul DAC ed alimentato mediante una tripla dalla stessa presa, vero?
Se posso dire la mia ....io uso un TP-Link D7.....non avverto differenze se collego direttamente i PC...ergo non mi complico la vita
Ritorno dopo un pò di silenzio ma ciò non vuol dire che sono rimasto fermo con il progetto LMS-Squeezelite. ;-)
Suggerisco di provare ad usare nella stringa si squeezelite il parametro "-u" in questo modo:
-u vL:2
ovvero filtro on very High quality ma ancora più importante ai fini dell' ascolto il filtro Chebyshev bandwidth ovvero quel "2" dopp "vL", la differenza all ascolto rispetto a quello di default ,con leggero roll-off, è netta e ben distinguibile in meglio.
Ciao a tutti inanzitutto ;-)
No, non uso attualmente il resampling vado "liscio" però ho notato che inserendo quel parametro la qualità all' ascolto migliora sensibilmente adesso sto provando anche il parametro "28" in fondo alla stringa non dovrebbe servire a nulla ma, ho l' impressione, che suoni in maniera leggermente diversa in meglio direi.
Liscio nel senso che fai resample con squeezelite?
paramatri da sperimentare comnq...
quel 28 dovrebbe essere la qualitá del resample...credo
cmnq la stringa dovrebbe essere cosi
: : : : : :
preso da Ubuntu Manpage: squeezelite - Lightweight headless Squeezebox emulator
codice:recipe
This part of the argument string is made up of a number of single-
character flags: [v|h|m|l|q][L|I|M][s][E|X]. The default value is hL.
v, h, m, l or q
are mutually exclusive and correspond to very high, high,
medium, low or quick quality.
L, I or M
correspond to linear, intermediate or minimum phase.
s changes resampling bandwidth from the default 95% (based on the
3dB point) to 99%.
E exception - avoids resampling if the output device supports the
playback sample rate natively.
X resamples to the maximum sample rate for the output device
("asynchronous" resampling).
Examples
-u vLs would use very high quality setting, linear phase filter
and steep cut-off.
-u hM would specify high quality, with the minimum phase filter.
-u hMX would specify high quality, with the minimum phase filter
and async upsampling to max device rate.
flags
The second optional argument to -u allows the user to specify the
following arguments (taken from the soxr.h header file), in hex:
#define SOXR_ROLLOFF_SMALL 0u /* <= 0.01 dB */
#define SOXR_ROLLOFF_MEDIUM 1u /* <= 0.35 dB */
#define SOXR_ROLLOFF_NONE 2u /* For Chebyshev bandwidth. */
#define SOXR_MAINTAIN_3DB_PT 4u /* Reserved for internal use. */
#define SOXR_HI_PREC_CLOCK 8u /* Increase 'irrational' ratio
accuracy. */
#define SOXR_DOUBLE_PRECISION 16u /* Use D.P. calcs even if precision
<= 20. */
#define SOXR_VR 32u /* Experimental, variable-rate
resampling. */
Examples
-u :2 would specify SOXR_ROLLOFF_NONE.
NB: In the example above the first option,, has not
been specified so would default to hL. Therefore, specifying -u
:2 is equivalent to having specified -u hL:2.
attenuation
Internally, data is passed to the SoX resample process as 32 bit
integers and output from the SoX resample process as 32 bit integers.
Why does this matter? There is the possibility that integer samples,
once resampled may be clipped (i.e. exceed the maximum value). By
default, if you do not specify an attenuation value, it will default to
-1db. A value of 0 on the command line, i.e. -u ::0 will disable the
default -1db attenuation being applied.
NB: Clipped samples will be logged. Keep an eye on the log file.
Examples
-u ::6 specifies to apply -6db (ie. halve the volume) prior to
the resampling process.
precision
The internal 'bit' precision used in the re-sampling calculations (ie.
quality).
NB: HQ = 20, VHQ = 28.
Examples
-u :::28 specifies 28-bit precision.
passband_end
A percentage value between 0 and 100, where 100 is the Nyquist
frequency. The default if not explicitly set is 91.3.
Examples
-u ::::98 specifies passband ends at 98 percent of the Nyquist
frequency.
stopband_start
A percentage value between 0 and 100, where 100 is the Nyquist
frequency. The default if not explicitly set is 100.
Examples
-u :::::100 specifies that the stopband starts at the Nyquist
frequency.
phase_response
A value between 0-100, where 0 is equivalent to the recipe M flag for
minimum phase, 25 is equivalent to the recipe I flag for intermediate
phase and 50 is equivalent to the recipe L flag for linear phase.
Examples
-u ::::::50 specifies linear phase.