se il file che mandi in play non é 44100...che succede con quel comando?
se il file che mandi in play non é 44100...che succede con quel comando?
Ciao a tutti.
Le cose si fanno sempre più complicate, man mano si avanza con l'indagine. Ancora non mi esprimo definitivamente, ma probabilmente scopriremo cose interessanti sul resampling.
Vi chiedo cortesemente di eseguire IN OS il comando:
sox -D file.flac -t wav -r 192000 -b 24 file_192_24.wav rate -v -b 90
dove file.flac è un qualsiasi file flac 44.1/16 esistente e file_192_24.wav è il file che ne risulterà.
Ora a me succede questo:
1.LMS su mac e Squeezelite su PC Win32 , file_192_24.wav suona correttamente ed è riconosciuto come PCM 192/24.
2.LMS su PC Win e Squeezelite su PC Win32 , file_192_24.wav suona come 'rumore bianco': squeezelite non lo riconosce come 192/24 ed apre a 44.1.
Non riesco, al momento, a provare altre configurazioni, chiedo pertanto a voi di provare e postarmi il risultato (ricordandomi anche la configurazione, ...sono pigro...), se lunedì vado al mare proverò con mac+ Alix/Voyage.
Vi prego di porre attenzione alla correttezza del comando dato, alle impostazioni di squeezelite (tutto standard, ev. solo -r 192000) ed al fatto che WAV venga mandato NATIVO da LMS, altrimenti si falsa la prova.
Mi interessano particolarmente configurazioni con LMS su Linux e squeezelite su win32 (mi aspetto si comporti come mac/Win32, ma...) qualsiasi/Linux e qualsiasi/Win64.
Michael non risponde, quando fa così è perchè o ho scritto una grossa c....a e/o ho messo il dito in una piaga (secondo me la prima è quasi certa, la seconda probabile).
Grazie.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Corretto:
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
-flc pcm * *
# FT:{START=--skip=%t}U:{END=--until=%v}
[flac] -dcs --force-raw-format --endian=little --sign=signed file.flac | [sox] -D -t raw -r 44100 -b 16 -c 2 -s -L - -t wav -r 192000 -b 24 rate -v -b 90
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
funge
player1:thin client+voyage - player2:futros450+Debian > Usb Transport: I2soverUSB + DAC (6x1704+I/V a tubi) - Attenuatore passivo Lightspeed
Ampli finale: OTL 6C33 - MyRef Fremen Ed. - Diff.: Diapason Adamantes II - Guida LMS+Squeezelite - B
player1:thin client+voyage - player2:futros450+Debian > Usb Transport: I2soverUSB + DAC (6x1704+I/V a tubi) - Attenuatore passivo Lightspeed
Ampli finale: OTL 6C33 - MyRef Fremen Ed. - Diff.: Diapason Adamantes II - Guida LMS+Squeezelite - B
Allora come fai a dire che funziona??? funziona nel senso che si sente il play...ma non puoi essere sicuro che esce un file a 192....
cat /proc/asound/card0/pcm0p/sub0/hw_params deve funzionare per forza....hai provato a mettere al posto di card0 card1?
le opzioni "-s/-u/-f/-A/-U/-o/-i/-a/-g" sono deprecate, al loro posto si deve usare l'opzione "-e" (encoding):
inoltre, quel "-D" lo toglierei: se il dithering non serve, sox non lo mette. Se invece serve, è fondamentale lasciare che sox ce lo metta!codice:Input & Output File Format Options These options apply to the input or output file whose name they immediately precede on the command line and are used mainly when working with headerless file formats or when specifying a format for the output file that is different to that of the input file. -b BITS, --bits BITS The number of bits (a.k.a. bit-depth or sometimes word-length) in each encoded sample. Not applicable to complex encodings such as MP3 or GSM. Not necessary with encodings that have a fixed number of bits, e.g. A/u-law, ADPCM. For an input file, the most common use for this option is to inform SoX of the number of bits per sample in a `raw' (`head- erless') audio file. For example sox -r 16k -e signed -b 8 input.raw output.wav converts a particular `raw' file to a self-describing `WAV' file. For an output file, this option can be used (perhaps along with -e) to set the output encoding size. By default (i.e. if this option is not given), the output encoding size will (providing it is supported by the output file type) be set to the input encoding size. For example sox input.cdda -b 24 output.wav converts raw CD digital audio (16-bit, signed-integer) to a 24-bit (signed-integer) `WAV' file. -1/-2/-3/-4/-8 The number of bytes in each encoded sample. Deprecated aliases for -b 8, -b 16, -b 24, -b 32, -b 64 respectively. -c CHANNELS, --channels CHANNELS The number of audio channels in the audio file. This can be any number greater than zero. For an input file, the most common use for this option is to inform SoX of the number of channels in a `raw' (`headerless') audio file. Occasionally, it may be useful to use this option with a `headered' file, in order to override the (presumably incorrect) value in the header - note that this is only supported with certain file types. Examples: sox -r 48k -e float -b 32 -c 2 input.raw output.wav converts a particular `raw' file to a self-describing `WAV' file. play -c 1 music.wav interprets the file data as belonging to a single channel regardless of what is indicated in the file header. Note that if the file does in fact have two channels, this will result in the file playing at half speed. For an output file, this option provides a shorthand for specifying that the channels effect should be invoked in order to change (if necessary) the number of channels in the audio signal to the number given. For example, the following two com- mands are equivalent: sox input.wav -c 1 output.wav bass -b 24 sox input.wav output.wav bass -b 24 channels 1 though the second form is more flexible as it allows the effects to be ordered arbitrarily. -e ENCODING, --encoding ENCODING The audio encoding type. Sometimes needed with file-types that support more than one encoding type. For example, with raw, WAV, or AU (but not, for example, with MP3 or FLAC). The available encoding types are as follows: signed-integer PCM data stored as signed (`two's complement') integers. Commonly used with a 16 or 24 -bit encoding size. A value of 0 represents minimum signal power. unsigned-integer PCM data stored as unsigned integers. Commonly used with an 8-bit encoding size. A value of 0 represents maximum signal power. floating-point PCM data stored as IEEE 753 single precision (32-bit) or double precision (64-bit) floating-point (`real') numbers. A value of 0 represents minimum signal power. a-law International telephony standard for logarithmic encoding to 8 bits per sample. It has a precision equivalent to roughly 13-bit PCM and is sometimes encoded with reversed bit-ordering (see the -X option). u-law, mu-law North American telephony standard for logarithmic encoding to 8 bits per sample. A.k.a. u-law. It has a precision equivalent to roughly 14-bit PCM and is sometimes encoded with reversed bit-ordering (see the -X option). oki-adpcm OKI (a.k.a. VOX, Dialogic, or Intel) 4-bit ADPCM; it has a precision equivalent to roughly 12-bit PCM. ADPCM is a form of audio compression that has a good compromise between audio quality and encoding/decoding speed. ima-adpcm IMA (a.k.a. DVI) 4-bit ADPCM; it has a precision equivalent to roughly 13-bit PCM. ms-adpcm Microsoft 4-bit ADPCM; it has a precision equivalent to roughly 14-bit PCM. gsm-full-rate GSM is currently used for the vast majority of the world's digital wireless telephone calls. It utilises several audio formats with different bit-rates and associated speech quality. SoX has support for GSM's original 13kbps `Full Rate' audio format. It is usually CPU-intensive to work with GSM audio. Encoding names can be abbreviated where this would not be ambiguous; e.g. `unsigned-integer' can be given as `un', but not `u' (ambiguous with `u-law'). For an input file, the most common use for this option is to inform SoX of the encoding of a `raw' (`headerless') audio file (see the examples in -b and -c above). For an output file, this option can be used (perhaps along with -b) to set the output encoding type For example sox input.cdda -e float output1.wav sox input.cdda -b 64 -e float output2.wav convert raw CD digital audio (16-bit, signed-integer) to floating-point `WAV' files (single & double precision respec- tively). By default (i.e. if this option is not given), the output encoding type will (providing it is supported by the output file type) be set to the input encoding type. -s/-u/-f/-A/-U/-o/-i/-a/-g Deprecated aliases for specifying the encoding types signed-integer, unsigned-integer, floating-point, a-law, mu-law, oki- adpcm, ima-adpcm, ms-adpcm, gsm-full-rate respectively (see -e above). --no-glob Specifies that filename `globbing' (wild-card matching) should not be performed by SoX on the following filename. For exam- ple, if the current directory contains the two files `five-seconds.wav' and `five*.wav', then play --no-glob "five*.wav" can be used to play just the single file `five*.wav'. -r, --rate RATE[k] Gives the sample rate in Hz (or kHz if appended with `k') of the file. For an input file, the most common use for this option is to inform SoX of the sample rate of a `raw' (`headerless') audio file (see the examples in -b and -c above). Occasionally it may be useful to use this option with a `headered' file, in order to override the (presumably incorrect) value in the header - note that this is only supported with certain file types. For example, if audio was recorded with a sample-rate of say 48k from a source that played back a little, say 1.5%, too slowly, then sox -r 48720 input.wav output.wav effectively corrects the speed by changing only the file header (but see also the speed effect for the more usual solution to this problem). For an output file, this option provides a shorthand for specifying that the rate effect should be invoked in order to change (if necessary) the sample rate of the audio signal to the given value. For example, the following two commands are equivalent: sox input.wav -r 48k output.wav bass -b 24 sox input.wav output.wav bass -b 24 rate 48k though the second form is more flexible as it allows rate options to be given, and allows the effects to be ordered arbi- trarily. -t, --type FILE-TYPE Gives the type of the audio file. For both input and output files, this option is commonly used to inform SoX of the type a `headerless' audio file (e.g. raw, mp3) where the actual/desired type cannot be determined from a given filename extension. For example: another-command | sox -t mp3 - output.wav sox input.wav -t raw output.bin It can also be used to override the type implied by an input filename extension, but if overriding with a type that has a header, SoX will exit with an appropriate error message if such a header is not actually present. See soxformat(7) for a list of supported file types. -L, --endian little -B, --endian big -x, --endian swap These options specify whether the byte-order of the audio data is, respectively, `little endian', `big endian', or the oppo- site to that of the system on which SoX is being used. Endianness applies only to data encoded as floating-point, or as signed or unsigned integers of 16 or more bits. It is often necessary to specify one of these options for headerless files, and sometimes necessary for (otherwise) self-describing files. A given endian-setting option may be ignored for an input file whose header contains a specific endianness identifier, or for an output file that is actually an audio device. N.B. Unlike other format characteristics, the endianness (byte, nibble, & bit ordering) of the input file is not automati- cally used for the output file; so, for example, when the following is run on a little-endian system: sox -B audio.s16 trimmed.s16 trim 2 trimmed.s16 will be created as little-endian; sox -B audio.s16 -B trimmed.s16 trim 2 must be used to preserve big-endianness in the output file. The -V option can be used to check the selected orderings. -N, --reverse-nibbles Specifies that the nibble ordering (i.e. the 2 halves of a byte) of the samples should be reversed; sometimes useful with ADPCM-based formats. N.B. See also N.B. in section on -x above. -X, --reverse-bits Specifies that the bit ordering of the samples should be reversed; sometimes useful with a few (mostly headerless) formats. N.B. See also N.B. in section on -x above.
Come dice il nome, uno stream "raw" contiene unicamente i dati "grezzi" e niente altro: non ci sono headers, quindi mancano le informazioni necessarie ad identificare il "significato" dei dati inviati (PCM piuttosto che altro, numero di canali, sample rate, bith depth, "endianess", ecc).
Per quello quando passi uno stream "raw" a sox devi necessariamente aggiungere anche le opzioni (-r, -b, -c, -e, ecc) per "spiegargli" come deve interpretare i dati che gli arrivano (mentre se usi wav o flac quelle informazioni sono già contenute nel file stesso e non devi aggiungere altro).
Non conosco il protocollo utilizzato da LMS/squeezelite ma, a meno che non sia previsto un "canale" attraverso il quale LMS comunica al renderer tali informazioni, per ovvi motivi semplicemente non puoi inviare uno stream "raw".
Per altro, non capisco perché mai tu voglia farlo: mentre ci sono ovvie differenze(*) tra l'inviare uno stream "compresso" (e.g. flac) piuttosto che uno non compresso (e.g. wav), non vedo quale possa essere la differenza tra l'inviare uno stream non compresso dotato di headers (wav) rispetto ad uno che non ne ha (raw), visto che la quantità di dati "extra" contenuti negli headers è del tutto insignificante; all'atto pratico non c'è nessuna differenza tra i due casi.
(*) uno stream compresso richiede una decodifica da parte del renderer, che comporta lavoro per la sua CPU, mentre per contro il secondo occupa molta più banda sul canale di rete, il che (tra l'altro) comporta a sua volta un certo carico "extra" del sistema del renderer per la gestione del maggiore flusso di dati di rete. In definitiva nei due casi (wav vs. flac) oltre ad un diverso carico di rete si ha anche un diverso "profilo" del carico di lavoro sul renderer. Senza dubbio si hanno quindi due situazioni diverse e non è privo di senso pensare di confrontarle (a priori è difficile dire quale delle due opzioni possa eventualmente essere preferibile ai nostri fini, ovviamente ammesso e non concesso che ci possa essere una qualche differenza ai fini pratici).
ovviamente... visto che fa esattamente la stessa cosa.
IMO è decisamente preferibile fare così, dato che in questo modo il processo è più semplice e soprattutto molto più "robusto" e flessibile:
infatti, passando direttamente a sox il flac di partenza, sox è in grado di riconoscere e gestire il "formato" (risoluzione, bit rate, ecc) dei dati in ingresso.
Al contrario, facendo una decodifica preventiva da flac a "raw" (con flac) per poi passare questo a sox ci si vincola ad un solo ed unico formato ben preciso: quello specificato nella riga di comando di sox!
Il che significa che, in tal caso (ammesso e non concesso che possa farlo) dovrebbe essere LMS a riconoscere e gestire files di ingresso con "formati" diversi da quello specificato (e.g. 16/44 piuttosto che 24/96) ed a gestire la cosa per mezzo di comandi diversi aggiunti nella configurazione di LMS (ne servirebbe uno per ogni possibile formato dei files in ingresso!)
ditto: non ha alcun senso. WAV è PCM. L'unica differenza è che oltre ai dati PCM un file wav contiene anche una manciata di bytes di "header" che spiegano al software che dovrà gestirli cosa sono e come vanno interpretati i dati PCM che seguono.
Non solo. Durante il debugging è opportuno aggiungere l'opzione "-V" per capire esattamente cosa accade:
conviene quindi utilizzare "-V3".codice:-V[level] Set verbosity. This is particularly useful for seeing how any automatic effects have been invoked by SoX. SoX displays messages on the console (stderr) according to the following verbosity levels: 0 No messages are shown at all; use the exit status to determine if an error has occurred. 1 Only error messages are shown. These are generated if SoX cannot complete the requested commands. 2 Warning messages are also shown. These are generated if SoX can complete the requested commands, but not exactly according to the requested command parameters, or if clipping occurs. 3 Descriptions of SoX's processing phases are also shown. Useful for seeing exactly how SoX is processing your audio. 4 and above Messages to help with debugging SoX are also shown. By default, the verbosity level is set to 2 (shows errors and warnings). Each occurrence of the -V option increases the ver- bosity level by 1. Alternatively, the verbosity level can be set to an absolute number by specifying it immediately after the -V, e.g. -V0 sets it to 0.
io faccio come te, salvo creare una sottocartella "extras", dove salvo tutto il resto. Finora la cosa non mi ha mai creato problemi di sorta. Però va detto che NON uso LMS/squeezelite ma MPD (o a volte altri player più "convenzionali"), per cui non garantisco. Prova...
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
player1:thin client+voyage - player2:futros450+Debian > Usb Transport: I2soverUSB + DAC (6x1704+I/V a tubi) - Attenuatore passivo Lightspeed
Ampli finale: OTL 6C33 - MyRef Fremen Ed. - Diff.: Diapason Adamantes II - Guida LMS+Squeezelite - B
Ci sono attualmente 3 utenti che stanno visualizzando questa discussione. (0 utenti e 3 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando