Frank Sinapsi
2006-11-07 17:41:48 UTC
Il contenitore Matroska permette di inserire in un MKV vari
tipi di sottotitoli, come qui descritto:
http://www.matroska.org/technical/specs/subtitles/index.html
In particolare:
- SRT (che conosco);
- USF (che non conosco);
- SSA/ASS (che non conosco);
- sotto forma di immagini bitmap (come vobsub)
Per ora, ho implementato nel mio programma l'estrazione
"corretta" dei sottotitoli SRT (quelli che hanno come codec
"S_TEXT/UTF8"), risolvendo il problema di calcolare i giusti
timecode di inizio/fine visualizzazione di ogni entry.
Pero' e' rimasto un problema: in un MKV, i sottotitoli SRT
vengono rappresentati in UTF-8 (una codifica di "Unicode").
L'utility "mkvextract" (del pacchetto "mkvtoolnix") permette
di estrarre le tracce da un mkv, e tra queste anche gli SRT.
Se, ad esempio, la traccia 4 del file test.mkv e' un
sottotitolo SRT (codec "S_TEXT/UTF8"), con il comando
mkvextract tracks test.mkv 4:test.srt
verra' creato il file "test.srt" che conterra' appunto i
sottotitoli in formato SRT (stranamente la mia versione di
"mkvextract" ha un bug per cui il file inizia con tre bytes
che non dovrebbero esserci...).
Una cosa interessante da osservare e' questa:
quando si inserisce un file di sottotitoli in un MKV con
"mkvmerge" (o "mmg", che sarebbe la sua gui), i sottotitoli
vengono convertiti dal charset locale (iso-8859-1) a UTF-8.
Quando, in seguito, si estraggono gli stessi sottotitoli
con "mkvextract", vengono lasciati in UTF-8!
Ad esempio, se nei sottotitoli compare la parola "Perché",
dopo l'estrazione da MKV, presentandolo al tipico lettore sa,
vi troverete visualizzata una cosa del tipo: "Perché".
Per riconvertirlo al set di caratteri iso-8859-1 occorrera'
usare una utility come "iconv", ad esempio cosi':
iconv -f utf-8 -t iso-8859-1 test.srt > test-latin.srt
Il problema e' che a me fa piu' comodo estrarre i sottotitoli
gia' in formato iso-8859-1, perche' i lettori da tavolo che
ho potuto testare supportano proprio quel set di caratteri
e ovviamente non supportano UTF-8.
Quindi, per l'estrazione nel mio programma, avevo usato la
funzione di conversione (che si chiama "iconv", proprio
come l'utility a riga di comando).
Quando pero', poco fa l'ho testato su un MKV che conteneva
sottotitoli SRT in cirillico, la conversione in iso-8859-1 e'
impossibile e quella funzione fallisce; il risultato e' che le
entries dei sottotitoli che non possono essere rappresentate
nell'alfabeto latino vengono rimosse, e alla fine mi resta
solo l'ultima entry (l'unica convertibile):
------------------------------------------------
1
00:02:25,080 --> 00:02:27,000
(Subtitles translated by ????)
------------------------------------------------
Allora ho pensato di procedere cosi':
- se la entry e' convertibile, la converto;
- se non lo e', la lascio in utf-8.
Pero' in questo modo si puo' ottenere un ibrido, che non e'
ne' iso-8859-1 ne' utf-8.
Come conviene fare?
Voglio dire, come sarebbe piu' utile?
Lasciare tutto in UTF-8 oppure convertire nel set di caratteri
usato dai lettori stand-alone (con i problemi discussi)?
tipi di sottotitoli, come qui descritto:
http://www.matroska.org/technical/specs/subtitles/index.html
In particolare:
- SRT (che conosco);
- USF (che non conosco);
- SSA/ASS (che non conosco);
- sotto forma di immagini bitmap (come vobsub)
Per ora, ho implementato nel mio programma l'estrazione
"corretta" dei sottotitoli SRT (quelli che hanno come codec
"S_TEXT/UTF8"), risolvendo il problema di calcolare i giusti
timecode di inizio/fine visualizzazione di ogni entry.
Pero' e' rimasto un problema: in un MKV, i sottotitoli SRT
vengono rappresentati in UTF-8 (una codifica di "Unicode").
L'utility "mkvextract" (del pacchetto "mkvtoolnix") permette
di estrarre le tracce da un mkv, e tra queste anche gli SRT.
Se, ad esempio, la traccia 4 del file test.mkv e' un
sottotitolo SRT (codec "S_TEXT/UTF8"), con il comando
mkvextract tracks test.mkv 4:test.srt
verra' creato il file "test.srt" che conterra' appunto i
sottotitoli in formato SRT (stranamente la mia versione di
"mkvextract" ha un bug per cui il file inizia con tre bytes
che non dovrebbero esserci...).
Una cosa interessante da osservare e' questa:
quando si inserisce un file di sottotitoli in un MKV con
"mkvmerge" (o "mmg", che sarebbe la sua gui), i sottotitoli
vengono convertiti dal charset locale (iso-8859-1) a UTF-8.
Quando, in seguito, si estraggono gli stessi sottotitoli
con "mkvextract", vengono lasciati in UTF-8!
Ad esempio, se nei sottotitoli compare la parola "Perché",
dopo l'estrazione da MKV, presentandolo al tipico lettore sa,
vi troverete visualizzata una cosa del tipo: "Perché".
Per riconvertirlo al set di caratteri iso-8859-1 occorrera'
usare una utility come "iconv", ad esempio cosi':
iconv -f utf-8 -t iso-8859-1 test.srt > test-latin.srt
Il problema e' che a me fa piu' comodo estrarre i sottotitoli
gia' in formato iso-8859-1, perche' i lettori da tavolo che
ho potuto testare supportano proprio quel set di caratteri
e ovviamente non supportano UTF-8.
Quindi, per l'estrazione nel mio programma, avevo usato la
funzione di conversione (che si chiama "iconv", proprio
come l'utility a riga di comando).
Quando pero', poco fa l'ho testato su un MKV che conteneva
sottotitoli SRT in cirillico, la conversione in iso-8859-1 e'
impossibile e quella funzione fallisce; il risultato e' che le
entries dei sottotitoli che non possono essere rappresentate
nell'alfabeto latino vengono rimosse, e alla fine mi resta
solo l'ultima entry (l'unica convertibile):
------------------------------------------------
1
00:02:25,080 --> 00:02:27,000
(Subtitles translated by ????)
------------------------------------------------
Allora ho pensato di procedere cosi':
- se la entry e' convertibile, la converto;
- se non lo e', la lascio in utf-8.
Pero' in questo modo si puo' ottenere un ibrido, che non e'
ne' iso-8859-1 ne' utf-8.
Come conviene fare?
Voglio dire, come sarebbe piu' utile?
Lasciare tutto in UTF-8 oppure convertire nel set di caratteri
usato dai lettori stand-alone (con i problemi discussi)?
--
Home page: http://fsinapsi.altervista.org
Home page: http://fsinapsi.altervista.org