Problem mit gebrannten DVDs...

Anzeige

Verstehe ich nicht so ganz. Wenn Fehler drin sind, dann sind Fehler drin. Da ist das Format völlig egal.

Wegschmeißen und nochmal aufnehmen.

Gag

 

Das Problem kenn ich, hab 007 aufgenommen, nur leider war ab der mitte der Ton etwa 3 sec langsamer als das Bild.

Es hat nix geholfen, also muxen, demuxen ....
Ist die Aufnahme mal versaut, dann wars das.

Ich hab festgestellt, das man die besten aufnahmen mit folgenden sachen erziehlt.

1. PVA
2. HD vorher defragmieren
3. viel Platz frei
4. nix weiteres am rechner machen.

Seit dem ich so verfahre, klappt es wunderbar.
Der letzte Bond vorgestern wurde ohne Fehler auf DVD gebrannt läc

Achja, zum zusammenbasteln vom mpg Files ist tmpeg bestens geeignet.

 

Also ich hab komischerweise noch nie Probleme mit asynchronem Ton gehabt. Hmmm...

Ich nehme mit der D-Box II mit der WinGrabEngine auf, schneide es mit Vidomi und brenne es mit DVD-Lab auf DVD. Das wars.

Ob und wie meine Platte fragmentiert ist, interessiert den Grabber doch nicht. Das Filesystem arbeitet doch transparent. Und so lange die Datenrate zum Wegschreiben ausreicht, gibt es da auch keine Probleme. Und die maximal 7 MBit/s sollte die schon gerade so mitmachen winken

Allerdings hab ich zum Grabben auch eine eigene Festplatte, die ich nur dazu verwende.

Sobald ich auch nur einen Resync in der MPEG-Datei im Film hab, wandert die in den Shredder. Ich mache mich da nicht eierig und versuche nochwas zu retten. Bei der Wiederholungsrate -- auch bei den ÖR -- muss man ja nur ein wenig warten.

Gag

 

Retten kann bei Fehlern neimand etwas, da habt ihr recht, aber Bild un Ton bleiben so syncron, da pvastrumento es zurecht schneidet.
Wie Gag schon schrieb, is es dann das beste neu aufzunehmen, sofern es nochmals kommt.....

whitman

 

..wenn fehler in den ts-packets aufgetreten sind, stimmt das. Es git aber genug fälle, wo der muxer die fehler produziert hat, weil sich irgendwas geändert hatte. Dann gab es zwar später einen fix, aber die aufnahmen waren verloren. Nicht so beim reinen ts-stream, denn da ist alles so, wie es vom sender kommt.

 

Wieso sollte der Muxer einen Fehler produzieren? Das ist ein fester Algorithmus, der immer nach demselben Schema arbeitet.
Er überlegt sich nicht mal eben so "Och, hier hab ich keine Lust und baue ein paar Fehler ein...".
Der Muxer "verschluckt" sich aber immer dann, wenn der eingehende Stream fehlerhaft ist.

Es kann zwar sein, dass andere Muxer solche Fehler anders behandeln oder dass der fehlerhafte Stream von dem Player trotzdem abgespielt wird, aber Tatsache ist, wenn der Muxer nicht muxt, dann ist da ein Fehler im Datenstrom -- und der kommt nicht vom Muxer!

Gag

 

..dass du dieser meinung bist, verwundert mich nicht winken Der muxer macht schon ne ganze menge und wenn er nicht richtig programmiert ist, funktioniert es nicht. Die einzelheiten will ich dir ersparen..

Hier ein beispiel eines logs von einem fehlerhaften mux, bei dem der ts absolut fehlerfrei ist. Hier ist es der sehr gute dvbrecorder von R2-D2 (lies doch mal das readme winken ). Mit anderen programmen lässt sich dieser stream übrigens auch als gemxtes mpeg korrekt aufnehmen. breites_

09:17:05: a/v recording started, trying to synchronize...
09:17:05: polling thread started
09:17:05: throwing away 596 bytes of unwanted audio data before first header
09:17:05: set audio stream ID to 0xc0
09:17:05: no audio frame found - throwing away 1268 bytes!
09:17:05: initialized audio frame PTS to 8:33:48.656
09:17:05: throwing away 64 bytes of audio data before first frame
09:17:05: new audio frame pts differs by 0:00:00.024 from old audio frame pts
09:17:05: 1 dropped audio frames detected - replaced with dummy frames at playtime 8:33:48.704
09:17:05: no audio frame found - throwing away 1436 bytes!
09:17:05: new audio frame pts differs by 0:00:00.024 from old audio frame pts
09:17:05: 1 dropped audio frames detected - replaced with dummy frames at playtime 8:33:48.752
09:17:05: throwing away 100 bytes of audio data before first frame
09:17:05: new audio frame pts differs by 0:00:00.024 from old audio frame pts
09:17:05: 1 dropped audio frames detected - replaced with dummy frames at playtime 8:33:48.776
09:17:05: video frames per PTS data set to 1
09:17:06: no audio frame found - throwing away 1400 bytes!
09:17:06: new audio frame pts differs by 0:00:00.024 from old audio frame pts
09:17:06: 1 dropped audio frames detected - replaced with dummy frames at playtime 8:33:48.872
09:17:06: throwing away 136 bytes of audio data before first frame
09:17:06: new audio frame pts differs by 0:00:00.024 from old audio frame pts
09:17:06: 1 dropped audio frames detected - replaced with dummy frames at playtime 8:33:48.896
09:17:06: no audio frame found - throwing away 1364 bytes!
09:17:06: new audio frame pts differs by 0:00:00.024 from old audio frame pts
09:17:06: 1 dropped audio frames detected - replaced with dummy frames at playtime 8:33:48.992
09:17:06: throwing away 172 bytes of audio data before first frame
09:17:06: new audio frame pts differs by 0:00:00.024 from old audio frame pts
.
.
.

..und so geht es weiter, bis man auf stop klickt ha!

 

Dieses Log bekommt man auf Direkt. Das liegt aber an Premiere, da die regelmäßig ein paar Audioframes zuviel senden. Der DVBRecorder lässt deshalb regelmässig eins fallen und alles bleibt synchron. Dies macht er aber erst seit der V. 19d, da R2D2 den Fehler (nicht seiner sondern von P) finden musste.

 

..gut erkannt, doch leider falsch. Das kommt vom CBS_NY transponder auf 16E winken

..auch die schlussfolgerung mit den zu viel gesendeten audio frames stimmt nicht, denn ein TS file vom selben transponder mit projectx demuxt, zeigt keine solchen besonderheiten. Premiere kann ich leider nicht testen winken Kannst du aber selbst testen, indem du z.b. mit dvbedit als ts aufnimmst breites_

=> File is DVB/MPEG-2 TS (Video/Audio/TTX PES)

=> demux

-> SID 0x1

-> PMT 0x20 refer to these Video/Audio/Text related PIDs :

< 0x1062 0x1063 >

--> PID 0x0 (PAT or others) (0x0 #1) -> ignored

--> PID 0x20 (PMT) (0xBC #2) -> ignored

ok> PID 0x1063 has PES-ID 0xC0 (MPEG Audio) (0x1B2C #38)

ok> PID 0x1062 has PES-ID 0xE0 (MPEG Video) (0x7B60 #169)

-> video basics: 720*480 @ 29.97fps @ 0.6735 (4:3) @ 7121600bps, vbvBuffer 112

dropping useless B-Frames @ GOP#0 / new Timecode 00:00:00.000

packs: 112365 100% 21277652

video: fr/ct/1p/cg/og/dg 637/1/0/0/31/0

videolength: 637f @ 00:00:21.250

===> new File: CBS_NY.mpv

--> MPEG Audio (0xC0) on PID 0x1063

Audio PTS: first packet 08:36:23.432, last packet 08:36:45.488

Video PTS: start 1.GOP 08:36:23.998, end last GOP 08:36:45.253

-> adjusting audio at video-timeline

=> src_audio: MPEG-1,Layer2,48000Hz,stereo,256kbps,noCRC @ 00:00:00.000

audio frames: wri/pre/skip/ins/add 885/0/0/0/0 @ 00:00:21.240 done..

<small>[ 07. November 2003, 12:13: Beitrag editiert von: sderrick ]</small>