Trittico2 ha scritto:
Bene, visto che t'interessano i metodi sprecisi, prosegui pure nella tua ricerca....
Su, non fare del sarcasmo, tu non mi stai antipatico e non mi piace che io stia antipatico a te.
E questo lo dico anche agli altri che a volte mi rispondono in modo un po' ambiguo e sospettosamente "critico".
(come, tra gli altri, chi fa affermazioni chiudendole con "!!": che bisogno c'è di urlare?
Ma questo è un caso particolare, in realtà mi riferisco anche ad altri post)
Trittico2 ha scritto:
Ti segnalo solamente che, oltre al gratuito RecTVEdit, ci sono altri software commerciali che si sforzano di capire il formato DVR.
Uno di questi è Cypheros TS-Doctor (a pagamento).
Sono d'accordo, ma io al momento non ho soldi da spendere né voglio crackare illegalmente dei programmi. Non ho alternative che usare mezzi free, anche se non potenti come quelli a pagamento. TS-Doctor e compagnia bella sono per me esclusi a priori.
Ho controllato. Effettivamente, per me che ora uso l'SRT-5222 è meglio usare RecTVEdit piuttosto che unire gli .mpg di una registrazione con un file joiner. Probabilmente lo split degli .mpg fatto dal decoder non è una semplice interruzione dei dati su un file (es. 001.mpg) e continuazione sul successivo (es. 002.mpg), perché in base ad un test fatto su una registrazione composta da "INFO.DVR" (32K), "000.MPG" (724MB) e "001.MPG" (164 MB ), si ha che:
1) unendo i due MPG con un file joiner e riproducendo il file "unione" con VLC, arrivati al frame in cui c'era in origine lo split, VLC riparte la riproduzione da capo (anche se il resto del filmato c'è, e lo si può verificare saltando manualmente il momento dello split: il resto del filmato si vede correttamente). Riproducendo il file unione con un altro lettore, Pot Player, invece, questo problema del ritorno a "0:00:00" non si verifica, ma si sente un glitch al momento dello stacco. Quindi l'unione dei due file è da dichiararsi imperfetta. Evidentemente a inizio e fine degli spezzoni, il decoder inserisce delle informazioni aggiuntive che non c'entrano col filmato vero e proprio, e questo impedisce che il semplice join dei file sia il flusso continuo di video e audio che io mi aspettavo.
2) la dimensione dei file uniti con il file joiner e con RecTVEdit è diversa: 888475 KB per il file joiner, 888254 per RecTVEdit. Quindi RecTVEdit, come dedotto dal punto 1), scarta delle informazioni che non appartengono al filmato.
D'ora in poi userò RecTVEdit per fare i join. Per lo meno ora che ho l'SRT-5222, perché il TS6291 che usavo prima non compare nella lista dei decoder supportati (per lo meno nella versione forse vecchia che ho io, ossia la 4.9.
Resta un solo problema: spesso mi capita di fare delle registrazioni di notte, con timer, molto più lunghe di quanto la trasmissione (film, telefilm, ecc.) duri effettivamente, perché gli orari dei palinsesti sono spesso approssimativi e non voglio rischiare di trovarmi una trasmissione registrata a metà (quante volte m'è capitato!). Quando ancora non sapevo di tutta la storia menzionata in cima a questo post, avevo l'abitudine di cancellare da pc gli spezzoni .MPG all'inizio e alla fine di una registrazione che non comprendevano effettivamente la trasmissione (film, telefilm, ecc.) che mi interessava. Così, per risparmiare spazio, in una registrazione che aveva creato spezzoni da 000.MPG a 005.MPG, cancellavo ad esempio lo 000.MPG e il 005.MPG, mantenendomi gli spezzoni da 001.MPG a 004.MPG. Ora, se si prova a fare il join con RecTVEdit (cioè aprire l'INFO.DVR ed esportare in TS, che poi è un semplice file .MPG) quando mancano alcuni degli spezzoni previsti evidentemente nell'INFO.DVR, RecTVEdit non può produrre alcun file "unione", dà errore. Per cui bisognerebbe ricadere sulla soluzione "file joiner" e unire gli spezzoni 001.MPG>004.MPG in modo "impreciso". Esiste però un workaround: basta avere sotto mano un qualsiasi altro spezzone .MPG registrato dal decoder (se ne può creare uno apposta facendo una REC dal decoder di 10 secondi, per esempio) che abbia piccole dimensioni (anche se vanno bene anche grandi, è solo una questione di comodità e velocità) e usarlo per rimpiazzare gli spezzoni mancanti, copiando e rinominandolo (nell'esempio fatto da me, quello di 6 spezzoni da 000 a 005) in modo da "ricreare" dei finti spezzoni (es: "000.MPG" e "005.MPG", se sono quelli gli spezzoni che erano stati cancellati). RecTVEdit, aprendo il file INFO.DVR, ora trova tutti i file della registrazione (anche se alcuni sono "finti") e siccome dentro INFO.DVR evidentemente c'è scritto solo il NOME degli spezzoni necessari, ma non la DIMENSIONE (che RecTVEdit legge invece dal file, non da INFO.DVR), l'esportazione in TS (.MPG) per creare un file unico va a buon fine. Dal file .MPG creato, si può così creare tramite FFmpeg o qualsiasi altro programma di conversione, l'output che si vuole facendo il trim o cut di tutte le parti della registrazione (soprattutto quelle finte, ovviamente) che non ci servono. Visto che abbiamo usato RecTVEdit per fare l'unione, invece che un file joiner, non ci saranno glitch tra i file "001.MPG", "002.MPG", "003.MPG" e "004.MPG". E questo era quello che ci interessava, tanto "000.MPG" e "005.MPG" li avremmo comunque dovuti tagliare anche in origine (prima di costruire la loro versione "finta") perché non contenevano la trasmissione (cioè il contenuto video/audio) che ci interessava.
Nota: nel test che ho fatto, avevo una registrazione costituita da 000.MPG (grande) e 001.MPG (piccolo). Ho cancellato 000.MPG e usato 001.MPG per rimpiazzarlo, facendone una copia e rinominandolo "000.MPG". L'export con RecTVEdit è andato a buon fine, ma questo test non garantisce che funzioni sempre: 001.MPG era infatti uno spezzone "di fine registrazione". Per verificare che questa procedura funzioni sempre, bisognerebbe fare altri test e usare come spezzoni di rimpiazzo (quelli finti) anche spezzoni "di inizio registrazione" (un piccolo 000.mpg, ad esempio, o un inevitabilmente grande 002.mpg).
[VEDI EDIT IN FONDO A QUESTO POST]
Ora che ho verificato che è meglio fare il join con RecTVEdit (se supporta il decoder in proprio possesso) piuttosto che un semplice file joiner, mi rimangono tre quesiti:
- RecTVEdit, in esportazione non crea alcun file INFO.DVR, per cui si è costretti a riprodurre il filmato dal "media player" del decoder, non come "registrazione ufficiale". Questo per me resta un problema. E non mi pare, da quel che ho visto, che RecTVEdit permetta di modificare l'elenco dei file-spezzone inclusi nella registrazione aperta dal programma. Si può cambiare solo Titolo, Riassunto e Descrizione. Sarebbe stato bello, così uno poteva ricreare una "registrazione" contenente un solo file (unendo gli spezzoni originali), magari convertendo anche il file .MPG a proprio piacimento (per esempio abbassandone il video bitrate per risparmiare spazio) e leggendola dal decoder senza essere costretti a usare il "media player" (che come ho già avuto modo di dire impedisce di fare una REC mentre lo si usa, e per me questo è un problema)
- RecTVEdit legge dal file INFO.DVR Titolo, Canale, Data di inizio, Durata, e elenco degli spezzoni. (la "taille", che credo sia la dimensione in MB, non mi risulta essere letta dall'INFO.DVR, perché quando ho creato lo spezzone finto di cui sopra, dal valore di "taille" totale e di "taille" dei singoli spezzoni, ho notato che corrispondevano alle dimensioni degli spezzoni da me creati e alla somma degli stessi, per cui questi valori li legge direttamente dai file-spezzoni, non da INFO.DVR. Ora il problema è che la "Durata", invece, la legge sicuramente da INFO.DVR, perché modificando gli spezzoni essa resta sempre la stessa, cioè la durata effettiva della registrazione effettuata. Questo, quando si esporta in TS(.MPG), potrebbe dare problemi nel timestamp (credo si chiami così) del file esportato, se si usano spezzoni finti, cioè con durata diversa da quella originale. Quando cioè si va a riprodurre un TS(.MPG) con un lettore da pc, è possibile che i valori del tempo (hh:mm:ss) siano sballati; ma non ho verificato. E' anche vero comunque, che se il TS(.MPG) esportato è usato per creare un nuovo file convertito (per esempio un bel MP4/h.263), in quest'ultimo non dovrebbe esserci alcun errore di timestamp, perché tutto viene ricalcolato e codificato nell'output MP4.
- Non ho capito perché RecTVEdit chiama "TS" (Transport Stream) un file MPG (quello che esporta unendo gli spezzoni della registrazione), mentre, per lo meno sul mio decoder, TS registra degli spezzoni in formato .DVR. So più o meno la differenza tra PS e TS, ma perché questa discordanza?
EDIT: ho provato ad aprire con RecTVEdit una registrazione che originariamente andava da 000.mpg a 003.mpg ma a cui avevo tolto proprio l'ultimo spezzone, lo 003. RecTVEdit non mi ha permesso di fare l'esportazione in TS perché ha riscontrato la discordanza tra numero di spezzoni previsti dall'INFO.DVR e quello degli .MPG effettivamente trovati nella cartella di registrazione. Allora ho creato lo spezzone 003 mancante usando un file MPG di 5MB (una mini registrazione di una decina di secondi), che in questo caso , essendo piazzata dopo il 002.mpg, è da considerare spezzone di "inizio registrazione" (anche se è pure uno spezzone di "fine registrazione", perché appunto è una registrazione di soli 14secondi già in origine). Ebbene, RecTVEdit ha accettato questo 003.MPG "fittizio" e ha permesso l'esportazione in TS che è andata QUASI totalmente a buon fine: gli spezzoni da 000.MPG a 002.MPG (quelli "veri") non hanno glitch durante il passaggio dall'uno all'altro, e anche lo spezzone finto (lo 003.MPG), è incluso nel filmato unito.
MA come avevo previsto c'è un problema di "timestamp" (se così si chiama): aprendo il filmato esportato con il lettore VLC, risulta essere lungo SOLO 14 secondi (come il finto spezzone 003.MPG), mentre dovrebbe durare quasi 2 ORE. Questo non crea problemi di visione, ma crea problemi nell'uso del cursore sulla timeline, oltre che essere comunque un errore "tecnico" nel file. Ovviamente se uno ha solo bisogno di usare questo file unione solo per riconvertirlo in un altro formato, per "trimmarlo" o togliere le parti di pubblicità, credo che il timestamp verrebbe ricalcolato durante l'eventuale ricodifica, e quindi sparirebbe, dando in output un filmato perfetto.
EDIT 2: Confermo la mia ipotesi: ho riconvertito il file esportato da RecTVEdit che ha la durata errata di soli 14 secondi invece che quasi due ore, e il file output (un mp4/h.264 nel mio caso) non ha alcun problema: la durata secondo il player VLC è 1:43:32 (appunto quasi due ore) e il cursore della time line funziona correttamente.
o quasi!
"girato in prestito a tempo indeterminato".
da ALIDVR.
