• Non sono ammesse registrazioni con indirizzi email temporanei usa e getta

Procurarsi RecTvEdit

Devo verificare se lo stesso principio si applica anche a file spezzettati dal mio precedente decoder che però creava file .mpg.
Nella mia ignoranza (non avevo ancora trovato RecTVEdit) pulivo la cartella dai file superflui per poi procedere a tempo debito (in pratica quando avrei avuto il tempo..) alla giunzione (con glitch..).. e dato che non servivano..
 
Adesso ho capito, il formato comunque è un comune .ts (MPEG transport stream). Potrebbe essere acquisito dal segnale ricevuto, così com'è (il DVB contiene proprio il .ts), oppure ricreato in locale dal decoder (remux tracce). Alcuni decoder lo rinominano .mts (una variante) ma in realtà è sempre un .ts (originale o ricreato in locale); altri ancora remuxano in .mpg (MPEG Program Stream, in tal caso è necessariamente un remux).

"formato Ali 3", sembrava parlassi di un altro formato file contenitore (non .ts), da cui il dubbio ;)
 
Non riesco a trovare informazioni sul formato Ali 3 di cui parli.

Volevo provare anche io.

Potresti postare un rapporto di mediainfo del file? Grazie

Se hai delle registrazioni spezzate in più file, prendi il secondo file e guarda se l'inizio è uguale alla fine del precedente file. Se è simile, prova subito i 47KiB (48128 byte).
Usa un hexeditor per il confronto.
Io ho usato HxD: è comodo per selezionare x byte partendo esattamente da dove vuoi (la maschera che appare per la selezione manuale ti chiede il numero di byte da selezionare e a partire da dove).
Non so come siano gli altri, non uso spesso tale tipo di editor e quando ti trovi bene con uno..
Se trovi una parte in comune, elimina dal secondo file e poi uniscili brutalmente con il copy /b.
E guarda il risultato.

Ti chiedo scusa in anticipo per l'ovvietà..
 
Adesso ho capito, il formato comunque è un comune .ts (transport stream). Potrebbe essere acquisito dal segnale ricevuto, così com'è (il DVB contiene proprio il .ts), oppure ricreato in locale dal decoder (remux tracce). Alcuni decoder lo rinominano .mts (una variante) ma in realtà è sempre un .ts (originale o ricreato in locale); altri ancora remuxano in .mpg (MPEG Program Stream, in tal caso è necessariamente un remux).

"formato Ali 3", sembrava parlassi di un altro formato file contenitore (non .ts), da cui il dubbio ;)

Ah.. ok!! certo!!
Tutto chiaro.
 
Se hai delle registrazioni spezzate in più file, prendi il secondo file e guarda se l'inizio è uguale alla fine del precedente file. Se è simile, prova subito i 47KiB (48128 byte).
Usa un hexeditor per il confronto.
Io ho usato HxD: è comodo per selezionare x byte partendo esattamente da dove vuoi (la maschera che appare per la selezione manuale ti chiede il numero di byte da selezionare e a partire da dove).
Non so come siano gli altri, non uso spesso tale tipo di editor e quando ti trovi bene con uno..
Se trovi una parte in comune, elimina dal secondo file e poi uniscili brutalmente con il copy /b.
E guarda il risultato.

Ti chiedo scusa in anticipo per l'ovvietà..

Di nulla, appena posso, penso stasera, provo e riporto qui ;)
 
Di nulla, appena posso, penso stasera, provo e riporto qui ;)
Prova anche usando il filtro aac_adtstoasc di ffmpeg
Codice:
ffmpeg -f concat -i mylist.txt -c copy -bsf:a aac_adtstoasc output.mp4
dove mylist.txt contiene la lista di input file .ts
 
Prova anche usando il filtro aac_adtstoasc di ffmpeg
Codice:
ffmpeg -f concat -i mylist.txt -c copy -bsf:a aac_adtstoasc output.mp4
dove mylist.txt contiene la lista di input file .ts

Non è che ti riferisci ad h264_mp4toannexb, o uno quelli sotto il filtro -bsf:v che 'sistemano' la parte video AVC? ... con l'audio non ho problemi irrisolvibili (nel mio caso è AC-3 e MP2, non ho AAC)... comunque ho provato, mancano parti video (singoli macroblocchi o al massimo 1 frame), non c'è molto da fare...

ho provato diversi di questi, perlomeno quelli che potrebbero essere risolutivi e che dovrebbero uniformare il flusso nel cosiddetto formato Annex B (con gli start code all'inizio dei NAL ed end code alla fine, come vuole il .ts (o avi) ):

https://ffmpeg.org/ffmpeg-bitstream-filters.html

La parte mancante o è veramente persa o è salvata in quei file del decoder... che però non so interpretare... forse si dovrebbe riuscire a individuare, magari a forza di tentativi se un frame o un pezzo di frame è memorizzato li dentro... Però è una rogna solo al pensiero...
 
Ultima modifica:
Prova anche usando il filtro aac_adtstoasc di ffmpeg
Codice:
ffmpeg -f concat -i mylist.txt -c copy -bsf:a aac_adtstoasc output.mp4
dove mylist.txt contiene la lista di input file .ts

Non andrà mai. Da quanto ho visto oggi non andrà alcun programma che non sappia interpretare i file ts creati dal chip Ali, formato file 3.0.
Ogni spezzone ha in testa un blocco che ripete l'ultima parte del file precedente e nell'unione i vari joiner non sanno come fare a gestirlo.
Per questo c'è il glitch.
Ho provato il trucco su una registrazione con audio EAC3 che RecTVEdit non riconosceva: perfetto.
Sono 8 file ts da 1GiB l'uno: eliminati i primi 48128 byte da tutti i file, tranne il primo, e poi uniti con copy /b.
Ho controllato ogni singolo salto: nemmeno una perdita.
Sto provando sulle tipologie di file mpg: li è totalmente diverso però ho trovato comunque qualcosa di interessante.
 
Non è che ti riferisci ad h264_mp4toannexb, o uno quelli sotto il filtro -bsf:v che 'sistemano' la parte video AVC? ... con l'audio non ho problemi irrisolvibili (nel mio caso è AC-3 e MP2, non ho AAC)... comunque ho provato, mancano parti video (singoli macroblocchi o al massimo 1 frame), non c'è molto da fare...

ho provato diversi di questi, perlomeno quelli che potrebbero essere risolutivi e che dovrebbero uniformare il flusso nel cosiddetto formato Annex B (con gli start code all'inizio dei NAL ed end code alla fine, come vuole il .ts (o avi) ):

https://ffmpeg.org/ffmpeg-bitstream-filters.html

La parte mancante o è veramente persa o è salvata in quei file del decoder... che però non so interpretare... forse si dovrebbe riuscire a individuare, magari a forza di tentativi se un frame o un pezzo di frame è memorizzato li dentro... Però è una rogna solo al pensiero...

Ti confermo che i file extra non c'entrano nulla.
i salti che vedi sono dovuti a materiale aggiuntivo che il programma di join non capisce e non sa come trattare nell'unione.
Questo, ovviamente, se parliamo per il modello del mio decoder, su altri sistemi non è detto vada (quasi probabile).

Il materiale dovrebbe essere così composto:

<header><contenuti vari><end>
<header=endfileprecedente><contenutivari><end>
<header=endfileprecedente><contenutivari><end>

i file extra servono al decoder per altre cose. Non credo servano per l'EPG: analizzando i file ts trovo l'EPG all'interno. Forse il teletext.
Poi c'è l'info3.dvr che, suppongo, 'governi'.

Se si elimina <header=endfileprecedente> da ogni file, tranne il primo.. che non ce l'ha.., e si unisce brutalmente tutto.. si ottiene un unico file pulito e completo (traccia video, tracce audio, EPG, etc.).
 
Ultima modifica:
Adesso vorrei provare ma ho un problema con l'hex editor che non ce la fa ad aprirmi file nell'ordine dei GB.

Temo però già ci sia una differenza. Nel mio caso anche i file di inizio registrazione sono corrotti, o meglio il decoder che ho usato inizia la registrazione senza iniziare necessariamente da un Key frame, inizia brutalmente da qualunque tipo di frame, per es. da un B-Frames... già questo impone un taglio in testa perché il flusso già così è errato... (VLC infatti si impianta subito, Mediaplayerclassic invece supera l'ostacolo senza problemi), niente di irrisolvibile, fosse solo questo... però per dirti che già è diverso il comportamento del decoder.
 
Ti confermo che i file extra non c'entrano nulla.
i salti che vedi sono dovuti a materiale aggiuntivo che il programma di join non capisce e non sa come trattare nell'unione.
Questo, ovviamente, se parliamo per il modello del mio decoder, su altri sistemi non è detto vada (quasi probabile).

Il materiale dovrebbe essere così composto:

<header><contenuti vari><end>
<header=endfileprecedente><contenutivari><end>
<header=endfileprecedente><contenutivari><end>

i file extra servono al decoder per altre cose. Non credo servano per l'EPG: analizzando i file ts trovo l'EPG all'interno. Forse il teletext.
Poi c'è l'info3.dvr che, suppongo, 'governi'.

Se si elimina <header=endfileprecedente> da ogni file, tranne il primo.. che non ce l'ha.., e si unisce brutalmente tutto.. si ottiene un unico file pulito e completo (traccia video, tracce audio, EPG, etc.).

Ho installato l'hex editor di cui hai parlato: HxD, molto meglio di quello che usavo io (ormai vecchiotto), e mi ha caricato istantaneamente i file grandi.
Cancellato la parte che dicevi, quindi da 0 a BBFF (lunghezza BC00 = 48128 decimali), unione con copy \b... ma purtroppo niente da fare, il glitch è rimasto invariato.
Ci stavo sperando perché anche senza quei 48kiB, il secondo file da solo veniva pure riprodotto perfettamente da MPC.

A sto punto penso che i file extra, almeno nel tuo caso, nella riproduzione con decoder servono anche per saltare quel pezzo doppione (più che inserire qualcosa, come invece pensavo io). In effetti certamente contengono un indice (lo si deduce dalle estensioni tipo idx che spesso hanno, anche se hanno formati diversi all'interno), evidentemente l'indice salta quel pezzo ridondante in testa al secondo file.


PS: nel mio caso sono dei file .mts effettivi (non .ts rinominati impropriamente dal decoder come .mts di cui ho parlato più su, cosa che fanno altri decoder), in pratica è lo stesso contenitore usato nel blu-ray.

.ts (o equivalenti) ->
https://en.wikipedia.org/wiki/MPEG_transport_stream

.mts (o equivalenti) ->
https://en.wikipedia.org/wiki/.m2ts
 
Ultima modifica:
Ho installato l'hex editor di cui hai parlato: HxD, molto meglio di quello che usavo io (ormai vecchiotto), e mi ha caricato istantaneamente i file grandi.
Cancellato la parte che dicevi, quindi da 0 a BBFF (lunghezza BC00 = 48128 decimali), unione con copy \b... ma purtroppo niente da fare, il glitch è rimasto invariato.
Ci stavo sperando perché anche senza quei 48kiB, il secondo file da solo veniva pure riprodotto perfettamente da MPC.

A sto punto penso che i file extra, almeno nel tuo caso, nella riproduzione con decoder servono anche per saltare quel pezzo doppione (più che inserire qualcosa, come invece pensavo io). In effetti certamente contengono un indice (lo si deduce dalle estensioni tipo idx che spesso hanno, anche se hanno formati diversi all'interno), evidentemente l'indice salta quel pezzo ridondante in testa al secondo file.


PS: nel mio caso sono dei file .mts effettivi (non .ts rinominati impropriamente dal decoder come .mts di cui ho parlato più su, cosa che fanno altri decoder), in pratica è lo stesso contenitore usato nel blu-ray.

.ts (o equivalenti) ->
https://en.wikipedia.org/wiki/MPEG_transport_stream

.mts (o equivalenti) ->
https://en.wikipedia.org/wiki/.m2ts

Ok, ovviamente la cosa funziona se parliamo dello stesso formato. I file aggiuntivi che ho io sono tutti .dvr, non c'è alcun .idx.
Il blocco da togliere è preciso di 48128 byte ed ho controllato se (e lo è) corrisponde alla parte finale del precedente file in sequenza: anche nel tuo caso è così? hai 47KiB all'inizio identici ai 47KiB della parte finale del precedente? Altrimenti, ovviamente, non funziona.

Al momento io uso RecTVEdit fino a che funziona. Se poi mi ritrovo tra le mani una registrazione 'moderna', eseguirò uno script che devo prepararmi per automatizzare il trim e l'unione. Devo trovare un 'dd' performante per windows da cli così da non fare a mano l'attività.

Per i file mpg.. mi sa che al momento mi tocca project x. Purtroppo a suo tempo eliminavo il materiale di contorno non sapendo dell'esistenza del RecTVEdit.. e non posso ricostruire nulla non avendo più il decoder per generarmi una registrazione pulita (non mi ricordo più nemmeno marca e modello..). Per fortuna non sono tante.
 
Ok, ovviamente la cosa funziona se parliamo dello stesso formato. I file aggiuntivi che ho io sono tutti .dvr, non c'è alcun .idx.
Il blocco da togliere è preciso di 48128 byte ed ho controllato se (e lo è) corrisponde alla parte finale del precedente file in sequenza: anche nel tuo caso è così? hai 47KiB all'inizio identici ai 47KiB della parte finale del precedente? Altrimenti, ovviamente, non funziona.

Al momento io uso RecTVEdit fino a che funziona. Se poi mi ritrovo tra le mani una registrazione 'moderna', eseguirò uno script che devo prepararmi per automatizzare il trim e l'unione. Devo trovare un 'dd' performante per windows da cli così da non fare a mano l'attività.

Per i file mpg.. mi sa che al momento mi tocca project x. Purtroppo a suo tempo eliminavo il materiale di contorno non sapendo dell'esistenza del RecTVEdit.. e non posso ricostruire nulla non avendo più il decoder per generarmi una registrazione pulita (non mi ricordo più nemmeno marca e modello..). Per fortuna non sono tante.

Oggi ho avuto un po' di tempo, ho riprovato TsMuxeR, ultima versione.
Per il mio tipo di decoder non c'è verso. E ha senso visto come sono i file.
Per il precedente modello (ho trovato una vecchissima registrazione in un supporto dimenticato.. era un Dikom DVBT135) ho visto che invece è perfetto con o senza file di supporto (.plt e .tmp).

Non so se TsMuxeR può essere utile per il tuo caso.

Una domanda: TSDoctor, che è a pagamento ma ha 30 gg di prova (per questo lo conosco), con i tuoi file funziona?
In teoria se ne capisce il formato potrebbe darti qualche informazione in più per cercare un eventuale player, joiner o documentazione utile a capirne la struttura.
Sempre che non siano strade già percorse..
 
Ok, ovviamente la cosa funziona se parliamo dello stesso formato. I file aggiuntivi che ho io sono tutti .dvr, non c'è alcun .idx.
Il blocco da togliere è preciso di 48128 byte ed ho controllato se (e lo è) corrisponde alla parte finale del precedente file in sequenza: anche nel tuo caso è così? hai 47KiB all'inizio identici ai 47KiB della parte finale del precedente? Altrimenti, ovviamente, non funziona.

Al momento io uso RecTVEdit fino a che funziona. Se poi mi ritrovo tra le mani una registrazione 'moderna', eseguirò uno script che devo prepararmi per automatizzare il trim e l'unione. Devo trovare un 'dd' performante per windows da cli così da non fare a mano l'attività.
No... purtroppo come vedi sono differenti:

(fine primo file)
file-A-finepezzo.png


(inizio secondo file)
file-B-iniziopezzo.png


per praticità ho messo in evidenza le parti finali dei 48kiB.

Per i file mpg.. mi sa che al momento mi tocca project x. Purtroppo a suo tempo eliminavo il materiale di contorno non sapendo dell'esistenza del RecTVEdit.. e non posso ricostruire nulla non avendo più il decoder per generarmi una registrazione pulita (non mi ricordo più nemmeno marca e modello..). Per fortuna non sono tante.
Con .mpg (a patto che sia mpeg-2/sd)non ho mai avuto problemi coi decoder che registrano così, nemmeno con .ts (sempre mpeg-2/SD però); da cui avevo sempre sospettato che il problema stava nella complessità di h.264 (ben maggiore dipendenza tra i fotogrammi e struttura del bitstream più articolata), rispetto a h.262/mpeg-2.

Ho sempre usato DGindex (ver. 1.5.8) per lo scopo.

DGindex è un decoder sw, praticamente carichi i file uno alla volta e lui crea un progetto (da usare per esempio con script Avisynth), e demuxa l'audio (.mp2 o ac-3). Si può usare anche come demuxer (mettendo l'apposita spunta di demux video) che al contempo unisce gli stream video dei file selezionati, oltre all'audio. In pratica alla fine ti ritrovi con un unico flusso video elementare .m2v e flusso audio mp2 (o mpa) o ac-3 (il tutto coi corretti delay). Dopo di ché rimuxi in .ts, .mkv o quello che vuoi tu.
 
Ultima modifica:
No... purtroppo come vedi sono differenti:

(fine primo file)
file-A-finepezzo.png


(inizio secondo file)
file-B-iniziopezzo.png


per praticità ho messo in evidenza le parti finali dei 48kiB.


Con .mpg (a patto che sia mpeg-2/sd)non ho mai avuto problemi coi decoder che registrano così, nemmeno con .ts (sempre mpeg-2/SD però); da cui avevo sempre sospettato che il problema stava nella complessità di h.264 (ben maggiore dipendenza tra i fotogrammi e struttura del bitstream più articolata), rispetto a h.262/mpeg-2.

Ho sempre usato DGindex (ver. 1.5.8) per lo scopo.

DGindex è un decoder sw, praticamente carichi i file uno alla volta e lui crea un progetto (da usare per esempio con script Avisynth), e demuxa l'audio (.mp2 o ac-3). Si può usare anche come demuxer (mettendo l'apposita spunta di demux video) che al contempo unisce gli stream video dei file selezionati, oltre all'audio. In pratica alla fine ti ritrovi con un unico flusso video elementare .m2v e flusso audio mp2 (o mpa) o ac-3 (il tutto coi corretti delay). Dopo di ché rimuxi in .ts, .mkv o quello che vuoi tu.

Non ci crederai.. ma ho provato pure quello.
Per ridurre un mio intervento al massimo e quindi lasciare solo elaborazione macchina.
Project x è molto simile (non so se lo conosci o l'hai mai usato).
Hai anche il grafico del flusso ed altre cosette.
Però non è HD.
Con gli mpg ho avuto pochi problemi però sempre per la stessa filosofia.. più automatizzo meno tempo perdo.
Quando il decoder vecchio si è guastato ed ho preso quello attuale.. ho avuto in più il problema del glitch molto evidente.
 
RecTVEdit mi ha risolto parecchio.
Almeno fino a qualche mese fa quando è apparso l'audio in EAC3 su alcune emittenti. Non lo capisce.. non sa cosa sia.
 
Con i decoder che mi salvavano in .mpg o in .ts (ma con canali in MPEG-2) non ho mai avuto problemi nell'unione dei file registrati, mai nessun glitch. I problemi mi sono nati coi decoder HD/H.264, come se non sapessero gestire meglio il flusso video e lo trattano in modo poco attento come se fosse mpeg-2 (che è più semplice e maneggevole).
Inoltre si somma il fatto che non c'è ragione che se l'HDD viene supportato anche in NTFS dal decoder (e funziona pure meglio così) qualche modello mi fa lo stesso lo split a 4 GiB come se fosse formattato in FAT32.

Projectx l'ho provato tanti anni fa, ma non mi serviva, mi andava benissimo come facevo:

File ingresso (MPEG-2) -> DGindex -> (script)Avisynth -> Virtualdub (editazione) -> File uscita (Xvid/MPEG-4 Visual)

Se non volevo ricomprimere usavo un altro programma molto simile a DGindex che si limitava solo al taglio dei file MPG/VOB.
 
Ultima modifica:
Con i decoder che mi salvavano in .mpg o in .ts (ma con canali in MPEG-2) non ho mai avuto problemi nell'unione dei file registrati, mai nessun glitch. I problemi mi sono nati coi decoder HD/H.264, come se non sapessero gestire meglio il flusso video e lo trattano in modo poco attento come se fosse mpeg-2 (che è più semplice e maneggevole).
Inoltre si somma il fatto che non c'è ragione che se l'HDD viene supportato anche in NTFS dal decoder (e funziona pure meglio così) qualche modello mi fa lo stesso lo split a 4 GiB come se fosse formattato in FAT32.

Projectx l'ho provato tanti anni fa, ma non mi serviva, mi andava benissimo come facevo:

File ingresso (MPEG-2) -> DGindex -> (script)Avisynth -> Virtualdub (editazione) -> File uscita (Xvid/MPEG-4 Visual)

Se non volevo ricomprimere usavo un altro programma molto simile a DGindex che si limitava solo al taglio dei file MPG/VOB.

Stesso mio problema. Hanno iniziato ad usare codec diversi e RecTVEdit non li capisce più.
 
Per il tuo problema, hai già provato TSDoctor, la demo, per vedere che tipo di formato file pensa siano le registrazioni (se lo capisce e riesce ad unire gli spezzoni, crea un file di log e li riporta le informazioni)?
Ovviamente se il tuo decoder (o, meglio, la registrazione) è compatibile.
Altra domanda: i file .mts che hai usato per il printscreen di cui sopra sono un formato usato anche per le videocamere (ad esempio Canon). Hai mai provato a metterli in una cartella, magari rinominandoli da 000 a xxx come li 'chiede' la telecamera, e ad usare uno dei software/player Canon per pc (dovrebbe essere possibile recuperare il software dalle pagine di supporto)?
In passato ho avuto una cam Canon ed il player era fluido: ma sempre lo stesso software poteva poi esportare il file in un unico file mp4.
Se ti riconosce i file (anche se non sono 'proprio' la stessa cosa) magari riesci ad unirli con questo software.
O magari te li riesporta in AVCHD ma a quel punto sono in un formato tale da poter essere usato da altri programmi che gestiscono l'unione di file AVCHD in modo pulito e se hai fortuna che li estrae correttamente.. anche la join potrebbe risultare pulita.
 
Grazie, per le info.

Ho analizzato ancora il video (senza estrapolarlo, per cui lasciandolo così com'è).

Purtroppo nel mio caso è impossibile unirli senza glitch o senza "pulire" tagliando altri frame, nel mio caso manca proprio un frame di "raccordo"

La sequenza di memorizzazione dei frame del flusso video AVC è tipo così:

IPBBBBBPBBBBB...


La sequenza in riproduzione dev'essere così (con frame nel giusto ordine temporale)

IBBBBBPBBBBBP...

i B-frame sono preditivi, derivano da I e P frames passati/futuri.

Nel caso di queste registrazioni, mi ritrovo con un I frame come ultimo frame del primo file, e con un B-frame come primo fotogramma nella seconda parte, il che è sintomo che manca necessariamente un P-frame, perché dopo un I ci dev'essere un P-frame obbligatoriamente come ordine di decodifica... quindi è un errore se c'è subito un B-frame e il decoder non sa decodifcarlo integralmente visto che parte dello stesso è nel P mancante... il che si verifica anche in testa al primo file: il decoder come dicevo registra di punto in bianco quando si avvia, della serie 'ndo coje coje' :) invece di aspettare un I-frame (o comunque un analogo K-frame) per avere un flusso corretto... invece partendo da un B-frame si ha già un flusso errato, ma niente di grave in testa al primo file, lo taglio fino al primo I o K-frame (o lo fa comunque il programma, tipo Avidemux). A questo punto ho quasi la certezza che raggiunti i 4GiB stoppa e riavvia la registrazione in automatico... l'errore già in testa nei primi file mi porta a pensare che faccia così anche per i secondi file che fa partire automaticamente. Altrimenti il P-frame lo dovrei avere da qualche parte... ma non c'è. In riproduzione col decoder si nota meno, ma un piccolo e poco percepibile "slittamento" lo fa quando passa al secondo file.
 
Ultima modifica:
Indietro
Alto Basso