Newsgroup: it.comp.software.divx
Titolo: [lunghino] supporto ai sottotitoli SRT

Anche se non ho finito di scriverlo, se qualcuno volesse
testare l'attuale versione di avinaptic, la segnalazione
di bug e consigli vari mi sarebbe molto utile...
Quando potro', aggiornero' la documentazione sul sito; nel
frattempo do' una breve (non troppo) spiegazione del nuovo
supporto ai sottotitoli SRT presenti nella versione presente
sul sito (8-01-2007).
Innanzitutto, vorrei rassicurare che quando si apre un
qualsiasi file con avinaptic, viene sempre aperto in sola
lettura, quindi non puo' venire modificato...
Per modificarlo, occorre sempre che l'utente lo chieda
esplicitamente e confermi di volerlo modificare (ad
esempio, per impostare i ritardi o cambiare il fourcc).
Naturalmente questo vale anche per i sottotitoli SRT.
Un'altra premessa e' che a partire da questa versione
avinaptic ha bisogno di usare un database SQLite come
"spazio di lavoro" temporaneo (in futuro, forse, potrei
usarlo per ricordare parametri di configurazione
personalizzata).
Quindi, la prima volta che lo mandate in esecuzione,
dovrebbe creare un file (vi viene segnalato quale). Se
tutto va bene, questo file verra' creato alla prima
esecuzione, e verra' sempre riutilizzato nelle successive.
Se volete, potete cancellarlo (mentre il programma non e'
in esecuzione), ma cosi' facendo verra' ricreato la volta
successiva...
Se qualcosa va storto (cioe', se vi dice che non riesce
a crearlo), fatemi sapere...
Quando si apre un SRT, si ottiene un rapporto con questi
campi:
--------------------------------------------------
[ Info sulla compatibilità ]
Analisi completata: OK
Numero entries: 1216
Terminazione linea: ms-dos
Codifica caratteri: ISO-8859-1
Tags usati: nessuno
Max righe per entry: 2
Max lunghezza entry: 47
Entries vuote: 0
Linee superflue: 0
Spazi superflui: 0
Sintassi timestamps: OK
Ultima entry: OK
Numerazione entries: OK
Timestamps per entry: OK
Timestamps globali: OK
--------------------------------------------------
A occhio e croce direi che questo file dovrebbe essere
abbastanza compatibile con i lettori da tavolo (perlomeno,
con i miei, lo e').
Se un file dovesse presentare qualche caratteristica che
puo' essere fastidiosa, cliccate sul nuovo pulsantino con
la lettera "A" (oppure menu Misc->Modifica_i_sottotitoli).
In questo modo le entries del file SRT verranno importate
dentro tabelle del database SQL, e si aprira' una nuova
finestra... vuota :-) perche' ancora devo scrivere la GUI.
Comunque, nella finestra vuota c'e' un menu, che gia'
adesso permette di fare le seguenti operazioni:
1) rimuovere le entries vuote (ammesso che ci siano);
2) rimuovere tutti i tag;
3) riformattare le entries;
4) esportare le entries attuali in un nuovo file SRT
   (File->Salva_sottotitoli_come...)
Chiarisco un punto fondamentale: le modifiche vengono
fatte esclusivamente sul database (il file SRT di partenza
non viene toccato); se si chiude quella finestra senza
avere esportato su un nuovo SRT, le modifiche vengono
perse ed e' come se non fosse successo nulla.
Le operazioni dovrebbero essere abbastanza chiare, eccetto
il punto 3) che adesso tento di spiegare:
quando chiede tale operazione, l'utente deve scegliere un
valore che sara' la massima larghezza consentita per ogni
riga di testo. Il programma non fara' altro che splittare
le righe troppo lunghe (cioe', che superano quella soglia)
accorpando le eccedenze con eventuali righe successive.
Tuttavia non si tratta di una completa riformattazione
perche' questa operazione puo' solo aumentare il numero
di righe (cioe', non puo' diminuirle accorpando righe piu'
corte della soglia...). Spero sia chiaro... :-)
Faccio un esempio che chiarira' tutto.
Supponiamo che nel file ci sia questa entry:
-----------------------------
339
00:25:03,160 --> 00:25:06,596
don't behave like a hoodlum! oh, honey, you do like making love with me, don't
you?
-----------------------------
l'entry e' costituita da due righe, la prima delle quali e'
lunga ben 78 caratteri (troppi per qualsiasi lettore SA) e
la seconda e' cortissima (4 caratteri).
Se applichiamo l'operazione "Riformatta le righe" e impostiamo
una soglia di 30, quando salveremo il nuovo SRT, ci troveremo
questa entry cosi' riscritta:
-----------------------------
339
00:25:03,160 --> 00:25:06,596
don't behave like a hoodlum!
oh, honey, you do like making
love with me, don't you?
-----------------------------
Tuttavia, se partiamo dalla nuova situazione, in cui la
lunghezza delle righe e' al massimo 30, e riapplichiamo la
stessa operazione impostando una soglia di 50, non
otteniamo nessun effetto. Perche' questa operazione serve
solo per splittare le linee troppo lunghe, non per
allungare le corte (e diminuire il numero di righe). Per
quest'altro scopo dovro' scrivere una nuova operazione...
Spero che sia tutto chiaro, in caso contrario fatemi sapere.
Naturalmente, dopo che si e' salvato un nuovo file SRT, e'
possibile riaprirlo con AVInaptic per controllarne le
caratteristiche (ed eventualmente modificarlo nuovamente).
Mi resta da dire che alcuni problemi del file di partenza
potrebbero essere risolti automaticamente in modo
trasparente: ad esempio, se ci sono timestamps scritti
male (ma che il mio parser riesce a riconoscere lo stesso),
il campo "Sintassi timestamps" sara' diverso da "OK";
nel nuovo file salvato dalla finestra vuota, tutti i
timestamps saranno sicuramente scritti bene (inoltre,
non ci saranno caratteri e linee superflue, e la
numerazione delle entries sara' sicuramente giusta).
Oltre alla GUI, mi resta da scrivere qualche altra
operazione, ad esempio, quelle per rimuovere (solo se
l'utente lo desidera) eventuali inconsistenze nei
timestamps...
Queste nuove parti del programma le ho scritte in breve
tempo e le ho testate pochissimo... mi e' parso che funzioni
tutto a dovere, ma per esperienza non ci giurerei troppo,
quindi se scoprite malfunzionamenti, segnalatemelo in modo
che possa risolverli.
-- 
Home page: 
http://fsinapsi.altervista.org

 che possa risolverli.
Ho provato a ricreare alcune situazioni di errore
che mi sono capitate nel tempo.
Creazione database OK
Con il solo salvataggio del file
Il solo salvataggio trasforma unix in msdos
Perfetto.  Ieri ho dovuto buttare un dvd a causa dell'unix.
Mi sembrava perfetto e l'ho chiuso senza clikkare su salva
quando l'ho aperto con EditPad... me lo trasforma anche lui...
I timestamps vengono corretti nel caso della mancanza di spazio
in ---> prima e dopo
Non vengono corretti se in --> ci sono due spazi vuoti prima o dopo
Se dopo la virgola non ci sono i millesimi vengono messi tre zeri
con eventuale incongruenza rilevabile con un secondo controllo
Eliminazione entry vuota e rinumerazione è ok
Tag rimossi.
Presenti 4 su 2 entry. Rimossi tutti
ma l'indicazione dice 4 su 1 entry
Se due entry sono attaccate (senza la linea vuota di separazione)
è possibile separarle ?
Accorciare le righe crea la terza riga.
Con i  due player che ho avuto la terza riga
non lo mai vista. Devo starci attento a
questa opzione...
Funzionamento corretto nel salvataggio del file.
Uno perde i dati originali solo se si impegna
a volerli perdere...
Sapere a quali entry ci sono più di due righe aiuterebbe molto.
E in generale sapere a che righe sono gli errori meno globali
non corretti automaticamente.
Per trovarli bisogna scorrere tutto il file...
S.E.&O.
-- 
by Isaac (The Original)
Qu...@excite.it
 - Non usare per messaggi privati
Fidolook 2002 (SL) 6.0.2800.94 - 3/3/2005 11:18:26 

 non corretti automaticamente.
queste cose dovrebbero diventare possibili quando scrivero' la GUI.
Pensavo di fare cosi':
al centro della finestra dovrebbe venire visualizzato il testo
della "entry corrente" (forse editabile). Quando apri la finestra
la "entry corrente" e' la prima; ma ci saranno dei pulsanti e una
barra per poter scorrere tutte le entries.
Inoltre ci saranno delle funzioni di ricerca che ti permetteranno
di spostarti su particolari entries. Ad esempio, potresti
chiedergli di trovarti la prossima entry (a partire dalla
corrente) che ha piu' di 2 righe. Se non ce ne sono, ti viene
comunicato; altrimenti l'entry trovata diventa la corrente.
Insomma, avrei in mente di fare una specie di text editor
(mooolto semplificato), ma orientato alle entries.
Grazie per il feedback. Ciao


 Grazie per il feedback. Ciao
Grazie a te.Ciao


 e ovvia rinumerazione al salvataggio.
l'avevo pensato anch'io.
Questa operazione la metto sicuramente.
Anche in questo caso bisogna pensare in termini generali:
applicando questa operazione potrebbe venire creata piu' di
una nuova entry.
Ti faccio un esempio: se una entry dovesse avere 5 righe e
applichi questa operazione specificando un massimo di 2
righe, tale entry verrebbe suddivisa in 3 entries (ne
vengono create due nuove). Per quanto riguarda i tempi,
io farei in questo modo:
se l'entry da 5 righe ha timestamps come questi:
00:00:04,000 -> 00:00:06,000
la durata di 2 secondi la suddividerei nel numero di
righe (5), quindi dividerei l'intervallo in base al
numero di righe delle nuove entries. Quindi, se le 5
righe vengono suddivise come 2+2+1 allora i nuovi
timestamps diventano:
00:00:04,000 -> 00:00:04,800
00:00:04,800 -> 00:00:05,600
00:00:05,600 -> 00:00:06,000
In altre parole, le prime due righe si prendono 800 ms
ciascuna, e la terza solo 400 ms (perche' ha una sola
riga di testo).
Hai idee diverse?
Per implementare questa operazione mi bastano pochi
minuti :-)
Se ti vengono in mente altre operazioni utili, dimmele,
con il modo in cui ho rappresentato i dati ci metto
pochissimo a realizzarle (basta scrivere qualche query
SQL e qualche funzione nel mio linguaggio)



 --------
mettere qualche millisecondo di incongruenza
nel tempo iniziale nelle entry create nuove per
ridurre visivamente lo spezzattamento del dialogo
che inizialmente almeno sul PC era su di una solo videata
00:00:04,000 -> 00:00:04,800
00:00:04,790 -> 00:00:05,600
00:00:05,590 -> 00:00:06,000
Ma se alcuni lettori da tavolo non digeriscono le incongruenze....
-----
Ho appena scaricato un un srt con 15 entry con
terze righe. Sarebbe giusto che mi dicesse che sono 15.
Anche se ho gia visto che non mi proverò nemmeno
a correggerle a mano. Sono anche lunghe...
-----
Apro un thread per una cosa strana che mi è capitato.
Se potessi togliermi la curiosità...


 terze righe. Sarebbe giusto che mi dicesse che sono 15.
prova con la nuova versione (ho uploadato solo lo zip
con il solo eseguibile, tanto il resto e' tutto uguale)
Cliccando su "Mostra statistiche" dovrebbe darti alcune
informazioni, tra cui anche:
- Entries che hanno almeno 3 righe: ...
(dovrebbe dirti: 15)
Ho messo anche l'operazione "Limita il numero di righe"
di cui parlavamo nel precedente post.
Per usarla, devi scegliere un numero (tu sceglierai 2);
a quel punto il programma prende tutte le entries che hanno
piu' righe di quel numero, e le spezzetta in piu' entries,
in base alle regole che ti avevo detto nel precedente post.
Poi controlla di nuovo le statistiche, e il risultante SRT,
per vedere che cosa ti ha tirato fuori.
L'operazione "Limita il numero di righe" puo' essere molto
lenta... l'ho scritta riciclando funzioni gia' scritte ed e'
molto inefficiente (le ottimizzazioni le faro' in un
secondo tempo, solo se necessarie)
Controlla sempre i risultati... non vorrei che ti fidassi
troppo del programma e poi ti ritrovi con un DVD masterizzato
da buttare perche' un SRT generato dal mio programma e'
sballato... :-)
Del resto ancora non l'ho usato nemmeno io, e non so se
queste operazioni che ho scritto si comportano bene o se
vanno "riaggiustate"...


 vanno "riaggiustate"...
Scaricherò la nuova versione e la proverò.
Però adesso sono obbligato a mettermi in pausa
almeno fino a domani pomeriggio...
Poi c'è l'altro post con un'immagine
e il messaggio di errore...
Grazie di nuovo.


 almeno fino a domani pomeriggio...
non c'e' fretta :-)


 Ma se alcuni lettori da tavolo non digeriscono le incongruenze....
Io tenderei ad evitarli perché ci sono lettori che proprio non ne vogliono
sapere. Anzi farei piuttosto:
00:00:04,000 -> 00:00:04,800
00:00:04,801 -> 00:00:05,600
00:00:05,601 -> 00:00:06,000
-- 
Saluti, Kap - 
http://www.lordkap.it

di bug e consigli vari mi sarebbe molto utile...
Non so se questa funzione è nella tua scaletta di cose da implementare
o già esiste un programma che faccia al caso ma a me interesserebbe un
programmino che in automatico mi converta dei sub per un filmato a 30
fps in sub per lo stesso filmato a 25 fps e, per compensare eventuali
spazzi vuoti allungati, cambiando il timestamp di un sub applichi la
stessa modifica a tutti i successivi.
Ciao
-- 
Fritz
Togli *ERASE* per rispondere in e-mail.

stessa modifica a tutti i successivi.
boh, un qualsiasi editor di sub lo fa senza problemi se non sbaglio
*_*
a me capita di farlo con filtro textsub di VDM, ma sicuramente puoi
farlo sia con subrip che con un programma tipo medusa o subtitle
workshop.
Per farti un esempio: stanotte avevo bisogno di impastare dei sub ad
un video jap (29.9)...aperto il video con vdm, aperto i sub con
textsub, impostato il tutto a 25 perche' mi servivano cosi' (taglio
corto xD), processato ed encodato senza problemi ;)
se non vuoi/devi impstarli al video allora,come detto su, sub worlshop
va benissimo 
------------------------------------------------
Nike:"Non chiamatela fortuna ma potere della casualita'!"
Kill Bill e' il mio vangelo,Tarantino il mio profeta!
"Xenon...aka SGGK"

[cut]
ho appena provato ad estrarre una traccia audio da un flv che non
riuscivo a trattare nemmeno con flv encoder ed ha funzionato a dovere!
grasssie mille del programmino (so che non e' lo scopo del 3d, ma e'
sempre un'info utile spero xD)
appena ho tempo provo a fare qualche esperimento coi sub! ;)


 stessa modifica a tutti i successivi.
non ho capito cosa intendi.
Se cambi un filmato da 30 a 25 fps, ricodificandolo, la durata in secondi
del filmato non cambia, quindi, se un personaggio dice una battuta in
un certo istante, l'istante in cui la dice e' lo stesso sia nella versione
a 30 che in quella a 25 fps. In altre parole, il file srt e' lo stesso.
Il discorso e' diverso se cambi un filmato da 23.976 a 25 fps, perche'
in questo caso si evita di ricodificare, ma ci si limita a un cambio
nominale del framerate negli headers, quindi, la durata in secondi del
filmato diminuisce (di un fattore 23.976/25), e un srt valido per
quello a 23.976 non e' piu' valido per quello a 25 (si ha un'asincronia
progressiva: le battute dei personaggi vengono scritte sempre piu' in
ritardo, rispetto a quando vengono effettivamente dette).
Per i sottotitoli "MicroDVD" vale esattamente l'opposto, perche' in
quel formato non vengono specificati gli istanti temporali, ma il
numero dei frames.
Ad ogni modo, effettuare una trasformazione lineare dei tempi e'
un'operazione che mettero' sicuramente (anche perche' ci vuole un
attimo :-))
Probabilmente mettero' anche i casi predefiniti 23.976->25 e
viceversa
Ciao


 00:00:05,601 -> 00:00:06,000
bisogna fare delle prove coi lettori e vedere come si comportano.
Ancora non le ho fatte...
Attualmente le regole che ho seguito sono queste:
ho considerato i timestamps di una entry "coerenti" ("coerenza
orizzontale" o "coerenza per entry") se e solo se il primo
timestamp e' strettamente minore del secondo.
Esempi:
questo e' coerente:
00:00:03,237 --> 00:00:08,000
questi due non lo sono:
00:00:03,237 --> 00:00:03,237
00:00:08,000 --> 00:00:03,237
poi ho definito "coerenza globale" se e solo se per ogni
coppia di entries adiacenti, il timestamp iniziale del
secondo e' maggiore o uguale al finale del primo.
Esempio:
questa e' una situazione coerente:
------------------------------------------
46
00:00:04,000 --> 00:00:04,800
[...]
47
00:00:04,800 --> 00:00:05,600
[...]
------------------------------------------
questa invece e' una situazione incoerente:
------------------------------------------
46
00:00:04,000 --> 00:00:04,800
[...]
47
00:00:04,790 --> 00:00:05,600
[...]
------------------------------------------
la considero incoerente perche' la entry 47 inizia prima che
finisca la 46... bisogna controllare come si comportano i
vari lettori: se scopro che alcuni lettori non accettano
srt in cui il tempo iniziale di una entry e' uguale al
finale della precedente, allora ridefiniro' la "coerenza
globale" come:
"per ogni coppia di entries adiacenti, il timestamp iniziale
del secondo e' strettamente maggiore al finale del primo"


 riuscivo a trattare nemmeno con flv encoder ed ha funzionato a dovere!
il contenitore FLV l'avevo aggiunto peoprio perche' volevo estrarre
gli mp3 da alcuni filmati :-) (tipicamente quelli di youtube)


non ho capito cosa intendi.
Ok, spiego meglio. Ho i sub italiani per il filmato americano di un
episodio della serie X quando lo stesso episodio viene trasmesso in
italia faccio il Divx o l'Xvid e vorrei rimettere gli stessi sub (per
confrontare le traduzioni) ma non vanno bene perchè sono fuori sinc
per il frame rate diverso, probabilmente si può usare la soluzione di
Xenon, subtitole workshop ce l'ho, utilizzato una volta non ci avevo
capito nulla, riproverò.


 capito nulla, riproverò.
i sottotitoli sono in formato SRT?
La prima cosa che dovresti controllare e' la durata di un episodio
americano (quello su cui i sottotitoli sono sincronizzati) e la
durata del corrispettivo trasmesso in italia.
Se i sottotitoli vanno fuori sinc, le durate devono essere diverse,
ma di quanto, precisamente?
Senza sapere il rapporto tra le due durate, non si sa quanto vanno
ampliati o ristretti i timestamps dei sottotitoli per farli tornare
in sincronia con il secondo filmato.
Se il rapporto fosse 30/25, questo vorrebbe dire che, se il filmato
americano durasse 50 minuti, il corrispettivo italiano dovrebbe
durare un'ora, cioe' ben 10 minuti in piu'; mi pare abbastanza
improbabile...


gli mp3 da alcuni filmati :-) (tipicamente quelli di youtube)
ahah..quoto! esattamente quello per cui l'ho usato xD
nel mentre rinnovo la promessa di testarlo a fondo nel weekend coi sub


 di bug e consigli vari mi sarebbe molto utile......
Un'altra funzione che potesti aggiungere è la rimozione delle frasi 
all'interno delle parentesi quadre [], solitamente sono i sub per non 
udenti.
***
Lo sto utilizzando con una serie di sub e sembra fare egregiamente il 
suo lavoro (elimino i tag, limito i caratteri a 40 e le righe a 3).
Però se apro direttamente il file con avinaptinc mi da un errore di 
*parsing fallito*...
Ho scoperto che ci sono delle entry così:
135
00:08:57,640 --> 00:09:-01,560
-- 
Willy
* /Il mio sito/: 
http://willygroup.altervista.org
* Faq di /it-alt.comp.software.mozilla/: 
http://snipurl.com/mozfaq
* /Contatti/: 
http://snipurl.com/contatti

 00:08:57,640 --> 00:09:-01,560
e' normale che fallisca perche' non e' corretto: il carattere '-' e'
di troppo.
Comunque, ho apportato una modifica al parser in modo che accetti
anche questi casi (in pratica, se c'e' un segno '-' davanti ai numeri
viene ignorato e nel rapporto vengono segnalate "imprecisioni nella
sintassi dei timestamps"), quindi dalla prossima versione ti
funzionera' anche in quei casi.
Quando fallisce il parsing, bisogna sempre guardare il campo "Numero
delle entries", poi basta aprire il file SRT con un text editor
e posizionarsi sulla entry successiva a quel numero, perche' e' in
quella posizione che il parsing e' fallito. A quel punto resta da
capire cosa ha provocato il fallimento... ed e' quello che hai fatto
tu :-)


 tu :-)
C'ho messo dieci minuti per trovare quel "-" nella prima entry 
segnalata! :-P


ma di quanto, precisamente?
L'americano, da che mi ricordo, siamo sui 43 minuti, mentre quello
italiano è 39-40 quindi dovremmo essere nel caso peggiore citato nella
tua precedente risposta cioè americano a 23.976 fps e italiano a 25
fps.


 fps.
puo' darsi che sia cosi'.
Nell'ultima versione del mio programma che ho messo sul sito, ho
aggiunto una operazione con cui puoi modificare i tempi di
visualizzazione dei sottotitoli, in base alle tue necessita'.
La nuova operazione si chiama "Trasformazione lineare"
(si trova nel menu "Edita" della finestra (ancora vuota) della
modifica dei sottotitoli).
Ti spiego come andrebbe usata nel tuo caso specifico.
Attivando tale operazione, si apre una finestrina, come quella che
vedi in questa immagine:
http://fsinapsi.altervista.org/tmp/trasf.png
Per definire una trasformazione lineare, occorre fare due
"mappature", cioe' scegliere due istanti di tempo di partenza e
farli corrispondere ad altrettanti istanti di tempo di arrivo.
Nel tuo caso, se ho capito bene, hai un file di sottotitoli che
va bene per un filmato di 43 minuti (supponiamo che sia a
23.976 fps) e lo vuoi adattare a un filmato che dura un po'
meno (perche' si suppone che sia lo stesso filmato, ma
riprodotto piu' velocemente, a 25 fps).
Allora dobbiamo scegliere le seguenti mappature:
00:00:00,000 -> 00:00:00,000
00:00:25,000 -> 00:00:23,976
Questo vuol dire che l'istante di tempo 0 attuale viene
lasciato come istante 0; invece, l'istante di tempo che
corrisponde a 25 secondi diventa l'istante 23.976 secondi.
In altre parole, le scritte vengono stampate un po' prima,
nella misura che corrisponde al cambio di framerate.
Spero che sia chiaro...
Dopo che hai confermato l'operazione, salvi il nuovo file di
sottotitoli e vedrai che i tempi si sono ristretti...
Questa nuova operazione e' molto generica e permette di fare
qualsiasi trasformazione lineare.
Ad esempio, supponiamo che le scritte vengano mostrate tutte
in anticipo di un secondo esatto rispetto a quando vengono
pronunciate. Quindi le vogliamo ritardare di un secondo.
Bastera' impostare questa trasformazione lineare:
00:00:00,000 -> 00:00:01,000
00:00:00,001 -> 00:00:01,001
In altre parole, l'istante 0 viene mandato in 1 secondo, e
l'istante che corrisponde a un millesimo di secondo viene
mandato in "1 secondo e un millesimo".
Due mappature sono necessarie e sufficienti per definire
una trasformazione lineare, quindi ogni altro istante di
tempo verra' automaticamente spostato di un secondo in
avanti.
Si noti che avremmo potuto anche impostare questi dati:
00:00:00,000 -> 00:00:01,000
00:00:06,000 -> 00:00:07,000
e avremmo ottenuto esattamente lo stesso risultato di
sopra; non c'e' un unico modo per esprimere una
trasformazione lineare dei tempi, in genere si usera'
quello piu' facile per la nostra intuizione...
In modo analogo, e' possibile "shiftare" i tempi in
anticipo.
E' anche possibile usare questa nuova operazione per
unire due file SRT che si riferiscono al primo e secondo
tempo di due AVI da unire: basterebbe "shiftare" in ritardo
i tempi del secondo (di una quantita' pari alla durata del
primo filmato), concatenare i due SRT, aprirli con il mio
programma (che si lamentera' della numerazione sbagliata)
e risalvarli con la numerazione corretta...
Per questo scopo, pero', aggiungero' una funzione apposita,
in modo da automatizzare tutti questi passaggi.


 passaggi.
*Ma che meraviglia!!!*
Bello bello bellO!
-- 
Saluti, Kap - 
www.lordkap.it
 - ¥'s Fan #01 - 
www.pianetalibri.com
 - VCC
We are wise enough to know we are wise enough not to interfere with the
way of a man or another world. - Captain Kirk - Star Trek TOS

Spero che sia chiaro...
Chiarissimo appena ho tempo provo, grazie mille.


 Chiarissimo appena ho tempo provo, grazie mille.
mi sono dimenticato di dire che, per impostare il valore
"00:00:25,000" bisogna digitare "25000" nel campo numerico
(il campo contiene i millisecondi, che vengono mostrati
a destra nella forma "hh:mm:ss,xxx")
Poi mi e' venuto in mente un metodo piu' generale di
sincronizzazione dei sottotitoli. Basta procedere cosi':
si cerca nel filmato una scena all'inizio dove qualcuno
parla, e ci si annota il tempo e la battuta;
si cerca una scena alla fine dove qualcuno parla, e ci si
annota il tempo e la battuta.
Poi si cercano tali battute nel file SRT, e si guardano i
tempi;
a questo punto si applica una trasformazione lineare,
mappando il tempo della prima battuta come compare nel SRT
sul tempo come compare nel filmato; stessa cosa per la
seconda battuta.
Il file SRT ottenuto in questo modo risultera' sincronizzato
con quel filmato...


con quel filmato...
Ho provato sia questo metodo che il precedente ma non sono riuscito, è
sincronizzato all'inizio ma verso la fine tende a derivare. Che player
si può usare che visualizzi anche i millisecondi? VLC si ferma ai
secondi mentre virtualdub si lamenta dell'audio VBR, converte l'header
in CBR ma poi si desincronizza il parlato quindi diventa un casino.


 si puň usare che visualizzi anche i millisecondi?
per avere il minimo errore, la cosa piu' importante e' che i due punti
siano il piu' possibile distanziati, quindi conviene scegliere la prima
e l'ultima entry. In questo caso una precisione a livello dei secondi
dovrebbe bastare.
Se prendi la prima e l'ultima, non puo' tendere a derivare verso la fine.
Hai controllato che i timestamps dei punti scelti, nel risultato, siano
quelli che hai impostato nella finestrina?


quelli che hai impostato nella finestrina?
No non ho verificato, avevo poco tempo e ho fatto una prova veloce.
Comunque ho preso la prima e la penultima battuta come riferimento. Ho
perņ pensato che se ci fossero dei tempi morti, frame di nero, diversi
tra il video americano e italiano questo potrebbe introdurre degli
anticipi/ritardi che fanno derivare la sincronia, dovrei controllare i
tempi dopo ogni stacco sul nero, ci riproverņ.


 anticipi/ritardi che fanno derivare la sincronia,
se ci sono differenze di tempi morti, questi non fanno derivare la
sincronia, ma introducono delle "asincronie locali" in un intorno
dei tempi morti.
Se tu fissi i due punti scegliendo la prima e la penultima battuta,
per definizione, dato che mappi quei due punti nei tempi in cui
devono andare, quelle due battute (la prima e la penultima) saranno
sicuramente sincronizzate...
Quindi, se hai delle asincronie, queste devono essere per forza in
parti che si trovano all'interno...
