Squeezelite R2 su WTFPlay OS

[antonellocaroli]

Qualcuno ricorda dove ne avevamo parlato? Non ricordo più esattamente i calcoli con cui avevo ricostruito il 'limite'...

Da queste parti + o -

http://www.nexthardware.com/forum/pc...tml#post957476

http://www.nexthardware.com/forum/pc...tml#post957514

[marcoc1712]

Da queste parti + o -

http://www.nexthardware.com/forum/pc...tml#post957476

http://www.nexthardware.com/forum/pc...tml#post957514

Grazie.

Ho quindi trovato una risposta in rete:

"Especially with the pipes on both sides of sox, there is no way
to precompute the length of the wav file and so it has to seek()
to update the length. In this case, it puts a maximum length
allowed value in header.

For most programs, including sox, its only a warning if the size
of the file doesn't match the header; just a warning. Maybe
the program can be updated to gracefully detect EOF and not treat
it as a failure... Especially in the case when the header
says its MAX_SIZE wav file. "


SOX potrebbe indicare una MAX_SIZE maggiore, ma fino a che non lo fa, deve essere gestito a valle o a monte. Vedo se posso fare qualcosa in squeezelite, ma mi piace poco, il workaround è 'spezzare' i files, magari usando un cue sheet.

[marcoc1712]

Grazie.

Ho quindi trovato una risposta in rete:

"Especially with the pipes on both sides of sox, there is no way
to precompute the length of the wav file and so it has to seek()
to update the length. In this case, it puts a maximum length
allowed value in header.

For most programs, including sox, its only a warning if the size
of the file doesn't match the header; just a warning. Maybe
the program can be updated to gracefully detect EOF and not treat
it as a failure... Especially in the case when the header
says its MAX_SIZE wav file. "


SOX potrebbe indicare una MAX_SIZE maggiore, ma fino a che non lo fa, deve essere gestito a valle o a monte. Vedo se posso fare qualcosa in squeezelite, ma mi piace poco, il workaround è 'spezzare' i files, magari usando un cue sheet.

La modifica di squeezelite per gestire 'correttamente' la cosa sarebbe abbastanza invasiva, dovrei in pratica riscrivere il decoder pcm, mentre potrei forzare la dimensione dell'audio ad un valore arbitrario altissimo nell'header, con probabili controindicazoni in altri casi, per cui dovrei almeno condizionarlo ad un parametro di lancio e rimarrebbe una porcata, dato che il problema andrebbe risolto alla radice.

Dato che il workaround di (usare un cue sheet per) 'spezzare' il file in segmenti contigui (così da mantenre il gapless) più corti di 10 minuti funziona senza problemi anche a 384 Khz (se si vuole usare 768 Khz bisogna probabilmente accorciarli ulteriormente) , credo preferbile usare quello fintanto che SOX non correrà ai ripari (magari inserendo un valore di MAX HEADER più elevato...).

Fatemi sapere se mi sfugge qualcosa e permangono problemi.

[UnixMan]

Dato che il workaround di (usare un cue sheet per) 'spezzare' il file in segmenti contigui (così da mantenre il gapless) più corti di 10 minuti funziona senza problemi anche a 384 Khz (se si vuole usare 768 Khz bisogna probabilmente accorciarli ulteriormente) , credo preferbile usare quello fintanto che SOX non correrà ai ripari (magari inserendo un valore di MAX HEADER più elevato...).

tentar non nuoce... p.f. usa direttamente una dimensione "compatibile" con 768K (o rendila configurabile).

Nel frattempo potremmo anche dare una occhiata ai sorgenti di sox per vedere quanto sia complesso modificare quel parametro...

[marcoc1712]

tentar non nuoce... p.f. usa direttamente una dimensione "compatibile" con 768K (o rendila configurabile).

Nel frattempo potremmo anche dare una occhiata ai sorgenti di sox per vedere quanto sia complesso modificare quel parametro...

...intendevo spezare manualmente! I files devono essere presentati a LMS già della dimensione masisma ammessa, ma forse ho trovato il modo per infiarmi in una soluzione diversa, la sto testando.

[marcoc1712]

Qualcuno riesce aprovare con file che certamente vanno in crisi normalmente?

https://drive.google.com/folderview?...28&usp=sharing

Mi aspetto arrivi in fondo senza problemi e senza più emettere quei messaggi di errore che riempivano il log, ma vorrei sapere se termina correttamente e va in pause al termine, liberando la scheda se si usa il -C.

Grazie.

[UnixMan]

Qualcuno riesce aprovare con file che certamente vanno in crisi normalmente?

https://drive.google.com/folderview?...28&usp=sharing

lo faccio ASAP, grazie!

[bigtube]

Qualcuno riesce aprovare con file che certamente vanno in crisi normalmente?

https://drive.google.com/folderview?...28&usp=sharing

Mi aspetto arrivi in fondo senza problemi e senza più emettere quei messaggi di errore che riempivano il log, ma vorrei sapere se termina correttamente e va in pause al termine, liberando la scheda se si usa il -C.

Grazie.

Marco ma una versione non Debian....statica ? Cosi la posso lanciare con Puppy o qualsiasi altra distro linux x86 non debian
(tipo squeezelite-mc2-i386)

[antonellocaroli]

Marco ma una versione non Debian....statica ? Cosi la posso lanciare con Puppy o qualsiasi altra distro linux x86 non debian
(tipo squeezelite-mc2-i386)

dovrebbero funzionare anche su puppy......sono solo eseguibili mi pare...

piú che alrtro la location é un piccolo problema per wget...

[marcoc1712]

dovrebbero funzionare anche su puppy......sono solo eseguibili mi pare...

piú che alrtro la location é un piccolo problema per wget...

Vorrei essere sicuro che funzioniprimadi committare su gitHub.