• COMUNICATO IMPORTANTE: ACCOUNT BLOCCATI (16/02/2024) Clicca sul link per leggere il comunicato
  • Non sono ammesse registrazioni con indirizzi email temporanei usa e getta

Procurarsi RecTvEdit

Lorenzo92

Digital-Forum New User
Registrato
23 Ottobre 2021
Messaggi
6
Buongiorno a tutti, sul PC ho decine di registrazioni effettuate negli anni passati con un vecchio Telesystem TS-6291 e con un più recente ATLANTIS Smartix DH18 preso su Amazon.
Come ben saprete questi due decoder spezzano le registrazioni in più file, nonostante i molti tentativi fatti con vari software (Avidemux, TSMuxer, MPEGStreamclip) e con diverse configurazioni, c'è sempre un problema di qualche tipo (o di sincro audio-video, o qualche errore in corrispondenza dei punti di giunzione dei file.
L'unico software che mi potrebbe aiutare è RecTvEdit, ma non sono riuscito a trovarlo. Qualcuno saprebbe aiutarmi nel reperirlo?
 
Ultima modifica:
Prova filmora se hai la possibilità oppure (non so gestisce quel tipo di file fremake)
 
Niente, nè Freemake, nè la linea di comando della discussione linkata da @Kikkosat funzionano.
 
Ultima modifica:
ciao @Lorenzo92 ho trovato la mia vecchia copia di RECTVEdit funziona tutto sempre perfettamente, lo stai cercando ancora ?
 
Ultima modifica:
Salve a tutti.

RecTVEdit con le registrazioni PVR da reti Mediaset non va più da qualche mese dato che per la parte audio usa un codec non previsto inizialmente dallo sviluppatore.
Quindi non sa come gestire il merge dei file.
E purtroppo il progetto è stato abbandonato da anni.
A parte Filmora, qualcuno ha provato altri sistemi open/free per fare il merge senza glitch?
Ho provato di tutto, da 'copy /b' ad Avidemux passando per tutti programmi che si definiscono 'perfetti per il merge'.
Al cambio del file c'è il 'salto'.
Project X funzionerebbe (non proprio al 100%) ma: 1, richiede una serie di passate dato che il risultato finale sono più file con tracce audio e video separate da riunire in un secondo momento (quindi tempi di merge esageratamente lunghi); 2, non va con risoluzioni HD (quindi praticamente non si può più usare).

A suo tempo ho provato a chiedere al produttore (io ho un TS6810 stealth) se in futuro avrebbero fornito un programma per poter avere un merge dei file delle registrazioni ma mi hanno detto che non era previsto.

Ho anche provato a cercare su siti legati al produttore del chip usato per salvare le registrazioni (ALI) ma non ho trovato nulla di interessante.

Mi chiedevo se qualcuno avesse ottenuto risultati migliori.

Grazie..
 
Per glitch intendi i punti di giuntura tra i file?

Penso che prima devi correggere il flusso h.264.

Puoi provare con mkvmerge ( mkv è più comodo da maneggiare dei .ts, almeno coi programmi gratuiti), in genere fa delle correzioni al flusso se lo trova "incoerente", però non risolve sempre, dipende da dove capita l'errore.

In ogni caso prova mkvmerge come prima cosa.


PS: copy /b non può risolvere, h.264 anche se estratto non è un formato raw "puro", ha una struttura ben più complessa di mpeg-2 o altri, che va rispettata, per cui non si può unire brutalmente le parti da unire... l'unione dev'essere più "smart", con cognizione di causa del programma che fa l'unione.
 
Ultima modifica:
Per glitch intendi i punti di giuntura tra i file?

Penso che prima devi correggere il flusso h.264.

Puoi provare con mkvmerge ( mkv è più comodo da maneggiare dei .ts, almeno coi programmi gratuiti), in genere fa delle correzioni al flusso se lo trova "incoerente", però non risolve sempre, dipende da dove capita l'errore.

In ogni caso prova mkvmerge come prima cosa.


PS: copy /b non può risolvere, h.264 anche se estratto non è un formato raw "puro", ha una struttura ben più complessa di mpeg-2 o altri, che va rispettata, per cui non si può unire brutalmente le parti da unire... l'unione dev'essere più "smart", con cognizione di causa del programma che fa l'unione.

Grazie.

Si, intendo il salto da un file all'altro: si vede la giunzione e quindi un glitch.
Ma non è un errore di trasmissione: è il file che viene spezzato come per esempio fa .zip quando comprime e genera file da 1GiB.
Serve poi qualcosa che sappia come unirli e RecTVEdit fa esattamente questo: mai avuto un problema di glitch.

Ho provato in passato anche MKVMerge, non va.
Ogni tanto riprovo un po' di tutto sperando nelle nuove versioni..
Anche l'ffmpeg fallisce. Quello che si comporta meglio di tutti, ma fallisce comunque a volte, è TSDuck.
Ho provato il comando copy in passato prima dell'H.264 (il /b fa la giunzione in binario altrimenti non va proprio.. esce una schifezza) ma il glitch resta.
Ho provato di tutto.

Non riesco proprio a capacitarmi sul fatto che non venga anche fornito un programma per unirli. In passato era fornito, con alcuni decoder (per non parlare poi per quelli usb per pc).
Mi rispondo solamente nel fatto che cerchino, per problemi di 'credits', di non fornire la possibilità di avere su pc quanto registrato. Un po' come alcuni tv che non permettono di vedere quanto registrato se non con la tv stessa.
Ed in effetti col decoder glitch non ce ne sono.. ma il suo player è pessimo (a dir poco..).
 
E' vero che non è un errore in trasmissione, però quello spezzare che fa il decoder, rende il flusso corrotto, nel senso che uno o più fotogrammi possono essere effettivamente corrotti o mancanti in testa al secondo file. Mancante può equivalere a corromperne altri, se il fotogramma è di quelli referenti di altri ( come una gerarchia). Il problema non è nei muxer per pc, sebbene alcuni facciano meglio e altri peggio, ma il problema è del decoder che dovrebbe splittare il file nel punto giusto, in particolare in corrispondenza degli IDR-frames (o Key frames più in generale), invece probabilmente si basano solo sulla dimensione e splittano bruscamente, raggiunti i 2 o i 4 GB (dipende dai decoder), ignorando le specifiche del flusso... la cosa fastidiosa è che per esempio due dei miei decoder splittano anche usando partizione ntfs che supporta file > 4GiB come se fosse FAT32. Per fortuna un modello no, e i file sono sempre precisi (anche come sincronia a/v del secondo 'troncone').

Ho fatto una prova con un mio decoder che splitta i file e effettivamente se analizzo il flusso , il secondo file è corrotto.
I problemi che riscontro sono 2 e possono verificarsi entrambi oppure 1 solo dei due oppure nessuno dei 2(nella maggioranza almeno uno dei casi uno dei due si verifica):

1) il file non inizia con un K-frame
2) manca qualche frame iniziale nel secondo file

Tieni conto in ogni caso, che qualche errore si potrebbe sempre avere in trasmissione, a prescindere da alla giuntura, e questo succede anche se non lo riscontri col player, magari con un altro salta fuori.

Alla fine, tranne in rari casi, se si vuole conservare la registrazione fatta bene senza errori, conviene convertire tutto ricomprimendo il video (tagliando la parte dei pochi fotogrammi che squadretta nel punto di giunzione, se si vuole, si può anche lasciare, il flusso ricodificato sarà visto come 'corretto'). L'audio invece è più maneggevole e gli errori sono più facili da trovare e risolvere senza problemi udibili... per cui si può anche evitare di ricomprimerlo...


I programmi che invece consentono di evitare il glitch, se ho capito bene, quelli nativi dei decoder, credo che salvino in quei piccoli file extra che inseriscono nella stessa cartella, ma in formato proprietario, ciò che poi aggiungono in tempo reale nel flusso standard nelle giunzioni... (per intenderci un po' come la lettura dei file .vob gestita tramite la struttura del dvd-video).
In pratica i .ts sono i flussi standard, potenzialmente corrotti e le correzioni nelle giunzioni le salvano in quei file, che però non sono standard e quindi i normali muxer non possono leggerli e fanno quello che possono...
 
Ultima modifica:
... Ho anche provato a cercare su siti legati al produttore del chip usato per salvare le registrazioni (ALI) ma non ho trovato nulla di interessante.

Mi chiedevo se qualcuno avesse ottenuto risultati migliori.

Con i file .dvr usavo Ali DVR Export Tool. Basta selezionare la cartella principale (o della singola registrazione), poi selezionare la registrazione e esportare il file .TS
 
Ho fatto qualche altra prova, visto che proprio in 'sti giorni mi sono ri-imbattuto in questo noioso , nonché annoso, problema.

Pensandoci bene il comando "copy /b" potrebbe essere giusto, a patto di estrarre preventivamente la traccia video elementare dai rispettivi file splittati dal decoder.

Perché anche se abbiamo 1 file (il secondo, supponendo che la registrazione sia suddivisa in due file), nel mio caso un .mts, che inizia con un b-frame che è formalmente scorretto (e per esempio, avidemux per rendere il flusso legale lo segherà fino al primo k-frame che trova nel file, perdendo così ulteriori frames intermedi ancora potenzialmente "sani"), se lo estraggo e lo unisco col comando copy /b si dovrebbe riallacciare alla parte finale della prima parte del flusso ancora integra nel primo file, quindi al k-frame di riferimento, presente alla fine del primo troncone... In teoria così dovrebbe funzionare, proprio come si può fare con gli audio (ac-3, mp2...), il problema è che di fatto non risolvo perché manca proprio almeno un frame tra un file e l'altro che il decoder evidentemente sacrifica... producendo così un leggero "glitch" in ogni caso.
Altro problema nel mio caso almeno, è che anche la 'testa' del primo file, inizia con b-frame... ma questo è meno grave perché in genere come tutti cerco di far partire la registrazione in anticipo, per cui poi taglio fino al primo k-frame (vlc per esempio va in crisi se non trova subito questo sull'mts), questo per ribadire che la colpa sta soprattutto nei decoder per queste problematiche (non tutti), quello che riescono a fare i player/muxer è in più.
 
E' vero che non è un errore in trasmissione, però quello spezzare che fa il decoder, rende il flusso corrotto, nel senso che uno o più fotogrammi possono essere effettivamente corrotti o mancanti in testa al secondo file. Mancante può equivalere a corromperne altri, se il fotogramma è di quelli referenti di altri ( come una gerarchia). Il problema non è nei muxer per pc, sebbene alcuni facciano meglio e altri peggio, ma il problema è del decoder che dovrebbe splittare il file nel punto giusto, in particolare in corrispondenza degli IDR-frames (o Key frames più in generale), invece probabilmente si basano solo sulla dimensione e splittano bruscamente, raggiunti i 2 o i 4 GB (dipende dai decoder), ignorando le specifiche del flusso... la cosa fastidiosa è che per esempio due dei miei decoder splittano anche usando partizione ntfs che supporta file > 4GiB come se fosse FAT32. Per fortuna un modello no, e i file sono sempre precisi (anche come sincronia a/v del secondo 'troncone').

Ho fatto una prova con un mio decoder che splitta i file e effettivamente se analizzo il flusso , il secondo file è corrotto.
I problemi che riscontro sono 2 e possono verificarsi entrambi oppure 1 solo dei due oppure nessuno dei 2(nella maggioranza almeno uno dei casi uno dei due si verifica):

1) il file non inizia con un K-frame
2) manca qualche frame iniziale nel secondo file

Tieni conto in ogni caso, che qualche errore si potrebbe sempre avere in trasmissione, a prescindere da alla giuntura, e questo succede anche se non lo riscontri col player, magari con un altro salta fuori.

Alla fine, tranne in rari casi, se si vuole conservare la registrazione fatta bene senza errori, conviene convertire tutto ricomprimendo il video (tagliando la parte dei pochi fotogrammi che squadretta nel punto di giunzione, se si vuole, si può anche lasciare, il flusso ricodificato sarà visto come 'corretto'). L'audio invece è più maneggevole e gli errori sono più facili da trovare e risolvere senza problemi udibili... per cui si può anche evitare di ricomprimerlo...


I programmi che invece consentono di evitare il glitch, se ho capito bene, quelli nativi dei decoder, credo che salvino in quei piccoli file extra che inseriscono nella stessa cartella, ma in formato proprietario, ciò che poi aggiungono in tempo reale nel flusso standard nelle giunzioni... (per intenderci un po' come la lettura dei file .vob gestita tramite la struttura del dvd-video).
In pratica i .ts sono i flussi standard, potenzialmente corrotti e le correzioni nelle giunzioni le salvano in quei file, che però non sono standard e quindi i normali muxer non possono leggerli e fanno quello che possono...

Se tratti gli spezzoni della registrazione come file singoli e li unisci, il glitch ci sarà sempre perché in generale questi programmi li trattano come singoli file 'aperti e chiusi correttamente' anche se in realtà quelli registrati non credo lo siano. Il programma mkvmerge infatti permette di unirli come singolo file oppure come file principale e 'figli'. Purtroppo col primo metodo è un disastro, col secondo meglio anche se qualche glitch rimane. Se dal file unito vai a togliere i fotogrammi del glitch perdi quasi sicuramente il sync con l'audio nel momento in cui converti da .ts ad altro (mkv, mp4, altro). RecTVEdit, invece, fa esattamente il contrario di quello che fa il decoder in registrazione e li unisce perfettamente senza glitch in poco più di qualche secondo. In pratica è un 'copy /b' specializzato per il formato .ts dei decoder. Sa come unirli in modo preciso e con continuità e restituisce un .ts completo di tutto (televideo, informazioni canale, etc.): se apri il file risultante con VLC vedi anche cambiare il titolo della finestra con il programma che sta mostrando e se nella registrazione ce ne sono più di uno, il titolo si adatta in modo preciso.
Ho provato anche TSDoctor: si comporta in modo simile, più lento, ma il risultato è quasi sempre ottimo. Però, come scritto, è più lento dato che analizza tutto il flusso (probabilmente a caccia di errori di trasmissione/registrazione dato che alla fine con lui puoi convertirlo in altro formato): in proporzione, sul mio pc, RecTVEdit può impiegare ad esempio 10 secondi per unire una registrazione che in totale cuba 10GiB (il tempo di leggere e riscrivere..) mentre TSDoctor supera abbondantemente il minuto (solo per l'unione).
 
Ho fatto qualche altra prova, visto che proprio in 'sti giorni mi sono ri-imbattuto in questo noioso , nonché annoso, problema.

Pensandoci bene il comando "copy /b" potrebbe essere giusto, a patto di estrarre preventivamente la traccia video elementare dai rispettivi file splittati dal decoder.

Perché anche se abbiamo 1 file (il secondo, supponendo che la registrazione sia suddivisa in due file), nel mio caso un .mts, che inizia con un b-frame che è formalmente scorretto (e per esempio, avidemux per rendere il flusso legale lo segherà fino al primo k-frame che trova nel file, perdendo così ulteriori frames intermedi ancora potenzialmente "sani"), se lo estraggo e lo unisco col comando copy /b si dovrebbe riallacciare alla parte finale della prima parte del flusso ancora integra nel primo file, quindi al k-frame di riferimento, presente alla fine del primo troncone... In teoria così dovrebbe funzionare, proprio come si può fare con gli audio (ac-3, mp2...), il problema è che di fatto non risolvo perché manca proprio almeno un frame tra un file e l'altro che il decoder evidentemente sacrifica... producendo così un leggero "glitch" in ogni caso.
Altro problema nel mio caso almeno, è che anche la 'testa' del primo file, inizia con b-frame... ma questo è meno grave perché in genere come tutti cerco di far partire la registrazione in anticipo, per cui poi taglio fino al primo k-frame (vlc per esempio va in crisi se non trova subito questo sull'mts), questo per ribadire che la colpa sta soprattutto nei decoder per queste problematiche (non tutti), quello che riescono a fare i player/muxer è in più.

Secondo me quando estrai i flussi e crei file separati per 'tracce', avviene anche una normalizzazione per cui se ad esempio hai 2 file il secondo potrebbe non 'partire' preciso causa split e quindi l'estrazione che crea il file video elimina lo 'sporco' per partire con un frame preciso. E poi nell'unione vedi i glitch.
RecTVEdit, invece, non lo fa e ti assicuro che non viene sacrificato alcun frame.
 
Provato con ffmpeg ?
Codice:
ffmpeg -i "concat:input1.ts|input2.ts|input3.ts" -c copy output.ts

sostituendo con i nomi corretti i file input e output
oppure ceando una lista di input in un file (es. mylist.txt) coi nomi dei file .ts da unire
Codice:
ffmpeg -f concat -i mylist.txt -c copy output.ts

_https://trac.ffmpeg.org/wiki/Concatenate
 
Oppure con Total Commader utilizzando la funzione unisci.

C'è anche la funzione dividi.

Hai tempi ho aperto il thread di Total Commander, programma essenziale.
 
Secondo me quando estrai i flussi e crei file separati per 'tracce', avviene anche una normalizzazione per cui se ad esempio hai 2 file il secondo potrebbe non 'partire' preciso causa split e quindi l'estrazione che crea il file video elimina lo 'sporco' per partire con un frame preciso. E poi nell'unione vedi i glitch.
RecTVEdit, invece, non lo fa e ti assicuro che non viene sacrificato alcun frame.

Non avviene una 'normalizzazione' del flusso, non con tutti i metodi di estrazione, altrimenti perderei anche i p e b-frames iniziali che in un flusso corretto non possono stare all'inizio del file. Nel mio caso, controllato anche con hex editor, rimane tutto il flusso elementare presente nel file prodotto dal decoder. E' il decoder che l'ha sacrificato oppure ha inserito la 'correzione' in quei piccoli file extra che crea durante la registrazione. Secondo me, a questo punto, varia da decoder a decoder la questione.
 
Indietro
Alto Basso