ANNUNCIO: C-3PO 1.0.10 rilasciato in beta

[marcoc1712]

Ho provato Trim, sembra funzionare, ma rompe il gapeless in quanto aggiunge un ritardo notevole, in funzione del tempo di trim inizale, il che lo rende inutilizzabile per i cue sheets.

NOTA BENE: non è nel manuale, ma è possibile usare anche i centesimi di secondo, con la notazione: trim 9:59.99, la cosa mi aveva fatto ben sperare inizialmente...

[UnixMan]

Ho provato Trim, sembra funzionare, ma rompe il gapeless in quanto aggiunge un ritardo notevole, in funzione del tempo di trim inizale, il che lo rende inutilizzabile per i cue sheets.

acc... seccante. Immagino sia perché probabilmente funziona "lasciando scorrere" lo stream in ingresso (alla massima velocità a cui lo riceve) fino al punto indicato. In effetti, mi chiedo: con le soluzioni attualmente adottate come funziona la cosa? Ad es., come fa flac a "saltare" al punto indicato senza introdurre ritardo?

[marcoc1712]

acc... seccante. Immagino sia perché probabilmente funziona "lasciando scorrere" lo stream in ingresso (alla massima velocità a cui lo riceve) fino al punto indicato. In effetti, mi chiedo: con le soluzioni attualmente adottate come funziona la cosa? Ad es., come fa flac a "saltare" al punto indicato senza introdurre ritardo?

Dividiamo la cosa in 2 aspetti:

a. In formati non compressi, la trasformazione del 'tempo' in bit, byte e blocco è una semplice operazione aritmetica, esistono diverse tecniche (applicative) per accedere a precise posizioni di un file, la 'sequenziale' è la più 'bovina' e di certo la meno efficiente in tutti i casi in cui il punto di inizio sia diverso dal primo blocco del file stesso. Pensa, ad esempio, ad un database.

b. In formati compressi non so di preciso, probabilmente nelle specifiche di formato ci sono dei 'marcatori' che consentono di 'approssimarsi' al punto del file ove inizare la conversione e quindi ricondursi al punto a, una sorta di 'directory' dei segmenti per come verranno ricostruiti.

Anni addietro, per comprimere ed archiviare file di 'grosse' dimensioni e non doverli ricostruire sequenzialmente, si usava suddividere gli stessi in segmenti più piccoli, compressi individualmente. In questo modo per accedere ad un punto X del file originario, non si era costretti a decomprimerlo tutto, ma si trasformava X in file.Y, così da doversi leggere sequenziamente solo il file (che normalmente corrispondeva alla singola bobina, o bobina.file o ...) fino ad arrivare al punto Y.

es. (uso il sistema decimale per comodità esplicativa)

file 1 dim. 1 GB X = 487.999.027 b.

se divido il file in 10 x 100 Mb (f0...f9) -> f4 Y = 87.999.027 b
se divido il file in 100 x 10 Mb (f0...f99) -> f48 Y = 7.999.027 b

e così via.

Più divido in segmenti piccoli, meno la compressione è efficace, ma più rapida è la navigazione.

[UnixMan]

[...]esistono diverse tecniche (applicative) per accedere a precise posizioni di un file, la 'sequenziale' è la più 'bovina' e di certo la meno efficiente in tutti i casi in cui il punto di inizio sia diverso dal primo blocco del file stesso. Pensa, ad esempio, ad un database.

ovviamente.

Il problema è che la cosa richiede accesso diretto (e "random") ad un file. Cosa che "trim", essendo un "effetto" che lavora invece su uno stream, all'interno di una sorta di "pipe" interna a SOX, ovviamente non può fare.

In effetti, avrei dovuto rispondermi da solo.

Evidentemente, in flac la possibilità di "saltare" ad una posizione è stata prevista per così dire a livello di "interfaccia esterna", direttamente nella gestione dell'accesso al file di input.