Originariamente inviato da UnixMan
come dicevo tempo addietro, uno stream (o un file) non è che una sequenza di bit. Che potrebbe rappresentare qualsiasi cosa: un brano musicale, una immagine, un filmato... o l'eseguibile di un programma.

Se non ho una "chiave di lettura" che mi dica esattamente come devo "raggruppare" ed interpretare i bit che compongono lo stream (o il file), quei bit non sono altro che quello: una sequenza di numeri binari del tutto priva di senso. Non ho assolutamente nessun modo per capire che cosa rappresentino!

Anche sapendo a priori che quello stream (o quel file) rappresenta uno stream PCM, l'informazione è incompleta ed assolutamente insufficiente: uno stream PCM "raw" (headerless) a 192K è del tutto indistinguibile da uno a 44.1K. Così come è altrettanto impossibile capire se si ha a che fare con uno stream composto da uno, due o più canali, se i campioni sono a 16 piuttosto che a 24 o 32 bit, se questi sono codificati come numeri interi o "reali" (floating point), big-endian o little-endian, ecc, ecc.

Anziché chiamare flac e/o sox, in quella riga di comando potrei anche metterci un bel "cat /dev/random", ed anche quello (uno stream composto da una sequenza casuale di bit) sarebbe del tutto indistinguibile da uno stream audio PCM raw!

La domanda quindi è: come accidenti fa LMS a sapere qual è il formato dei dati che gli vengono mandati indietro dai comandi esterni? (ad es. dopo l'upsampling?)

Le uniche cose sensate che LMS potrebbe fare avendo a che fare con uno stream PCM "raw" (headerless) sono:

1) imporre che gli stream che riceve "di ritorno" dai comandi esterni (se PCM) abbiano tutti, sempre e solo un ben preciso formato (predeterminato).

2) assumere che lo stream in uscita abbia sempre esattamente lo stesso formato dello stream in ingresso.

In entrambi i casi, per ovvi motivi ciò escluderebbe qualsiasi possibilità di fare resampling (o qualsiasi altra elaborazione che alteri il formato dello stream).

Oppure... oppure, c'è solo un'altra possibilità. Brutta, sporca, oscena, limitata e limitante, portatrice di bug e di problemi infiniti... in una parola semplicemente indecente:

3) che LMS interpreti le righe di comando (dei comandi esterni) che vengono inserite nel suo file di configurazione e ricavi da quelle il formato da utilizzare! :o

Se così fosse, si spiegherebbe come ha fatto a funzionarti... ed al tempo stesso perché i comandi esterni sembrano funzionare solo con ben determinate righe di comando e non con altre, pur perfettamente lecite (e magari anche più "logiche").

(ma mi rifiuto di crederlo. Se così fosse... non avrei parole: LMS non sarebbe un software decente, ma solo uno sporco "hack", semplicemente osceno e indecente, che non avrebbe mai dovuto essere distribuito. Tanto meno come prodotto commerciale o giù di li).
Per farla breve, LMS NON imposta MAI i valori del resample, lo lascia fare al convert.conf e/o alla combinazione delle richieste li specificate, le specifiche dei singoli formati e le capacità di rendering dei diversi modelli di lettore, mediante una complicata serie di incroci tra tabelle di definizione delle capability dei diversi modelli di lettore, le caratteristiche dei formati e le specifiche richieste.

Come scrivevo, è ovvio che il focus era il downsample, al fine di poter gestire lettori con limitate capacità di formato (es. solo MP3) e/o di bitrate (banda), tant'è che di sample rate in se tratta raramete, in questo senso LMS fa da broker tra le richieste del convert.conf ed i codec disponibili, nulla di più.

In nessun modo 'interpreta' le righe di comando, però prevede che queste siano scritte in conformità al 'suo' standard, quindi utilizzando le variabili ed i comandi di sostituzione che mette a disposizione, utilizzando al di fuori di queste limitazioni in alcuni casi funziona in altri ...non proprio...

Ovviamente non è come per 2) altrimenti non funzionerebbe in nessun caso l'upsampling o il downsampling, ma è certamente così nei casi in cui il formato di uscita è PCM.


Originariamente inviato da UnixMan
c
Azz, Marco, ma è OVVIO!

Per il motivo di cui sopra: PCM (raw) non ha header, per cui LMS semplicemente NON ha nessun modo per sapere quale sia il formato dei dati che gli "ritornano" dal comando esterno!
Si, questo lo capisco e capisco anche che a LMS non importi nemmeno saperlo, lui si limita a passare lo stream come dati e scambiare una serie di messaggi di protocollo con i lettori, tra i quali quello che contiene l'url del file di origine.

Ma i lettori devono pur interpretare lo stream... Allora perchè usare due meccanismi diversi? Perchè non passare direttamente il WAV/AIF con l'header esattamente come avviene per il flac?

Probabilmente è un retaggio del passato.