Dolby Tonaussetzer - was tun?

[Varta]

Mit dem analogen Stereoton gab es bei mir nie Probleme.

Aber nachdem ich nun eine Surround-Anlage über den optischen Ausgang angeschlossen habe, gibt es ca. 1-2 Tonaussetzer pro Stunde. Diese halten ein paar Sekunden an, danach ist der Ton wieder da.

Beobachtet habe ich dies beim Abspielen von Aufnahmen in Dolby Digital von Premiere, sowohl bei der Firmware von Sept. 05 als auch Dez. 06.

Laut Suchfunktion bin ich nicht alleine mit diesem Problem. Nur, was tut man dagegen?

[r3d3]

Abwarten und auf das Wunder einer funktionierenden Firmware hoffen...

[Gerti]

Hi!

Die Aussetzer können auch andere Ursachen haben.
Treten die Aussetzer immer an der selben Stelle in der Wiedergabe auf?

Gruß,
Gerti

[Varta]

[quote=""Gerti""]Die Aussetzer können auch andere Ursachen haben.
Treten die Aussetzer immer an der selben Stelle in der Wiedergabe auf?[/quote]

Ja, so ist es.

Ich habe es gerade bei einem Film nachgeprüft, den ich von Premiere aufgenommen hatte. Dieser liegt unverschlüsselt auf der Platte.

An einer bestimmten Stelle fällt der DD Ton komplett aus und setzt 6 Sekunden später wieder ein. Eine Bildstörung ist hier nicht zu sehen.

Spiele ich die selbe Stelle über die AUTO-Tonspur (nicht DD, aber dennoch über die optische Verbindung) ab, so läuft der Ton störungsfrei durch.

Was würdest Du als Ursache, oder noch besser als Abhilfe, vermuten?

[Gerti]

Hi!

Wenn es immer die selbe Stelle ist, dürfte es ein Fehler im Stream sein.
Du kannst die Aufnahme ja mal auf den PC übertragen und mit ProjektX zerlegen. Das sollte Dir dann ja anzeigen, ob der Stream fehlerhaft ist.

Gruß,
Gerti

[Varta]

Ich habe die Aufnahme wie vorgeschlagen mit ProjectX aufgetrennt.

Die Logdatei habe ich unten angehängt, ich weiß ehrlich gesagt nicht, wie die zu interpretieren ist. Die Stelle, an der der Topfield mit dem Ton aussetzt, befindet sich jedenfalls bei 0:03:13.

Was mir aber auffällt ist, dass die aus ProjectX resultierende *.ac3 Datei, wenn ich sie mit VLC auf dem PC abspiele, den Tonaussetzer nicht enthält.

Dies würde für mich nahelegen, dass der Stream in Ordnung ist, sonst könnte VLC ihn ja nicht wiedergeben. Woran könnte es denn jetzt noch liegen?


--- Logdatei folgt ---

[18:05:11.343] Mittwoch, 10. Januar 2007 19.05 Uhr CET
[18:05:11.343] ProjectX 0.90.4.00 (30.03.2006)
[18:05:11.468]
[18:05:11.468] -> working with collection 0
[18:05:11.468]
[18:05:11.468] -> save big log file
[18:05:11.468] -> save normal log file
[18:05:11.468] -> write all video data
[18:05:11.484] -> write all other data
[18:05:11.484] -> patch c.d.flagged infos of pictures
[18:05:11.484] -> add sequence end code
[18:05:11.500] -> set resolution in SDE
[18:05:11.500] -> PVA: strictly specs. for audio streams
[18:05:11.500] -> VOB: determine diff. Cell timelines
[18:05:11.515] -> TS: ignore scrambled packets
[18:05:11.515] -> TS: enhanced search for open packets
[18:05:11.531] -> TS: join file segments (of Dreambox®)
[18:05:11.531] -> TS: generate PMT stream dependent
[18:05:11.546] -> get only enclosed PES/TS packets
[18:05:11.546] -> concatenate different recordings
[18:05:11.546] -> ensure 1st PES-packet start with video
[18:05:11.562] -> generate PCR/SCR from PTS
[18:05:11.562]
[18:05:11.578] -> write output files to: 'D:\temp\topfield'
[18:05:11.609]
[18:05:11.609] -> Input File 0: 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale).rec' (3.266.543.616 bytes)
[18:05:11.609] -> Filetype is TS (generic PES Container)
[18:05:11.609] -> demux
[18:05:11.671] -> Service ID 0x9
[18:05:11.687] -> PMT 0x66 refers to these usable streams:
[18:05:11.703] Video:
[18:05:11.703] PID: 0x2FF(#2)
[18:05:11.718] Audio:
[18:05:11.718] PID: 0x300(#3)(deu)
PID: 0x301(#6)(deu)
PID: 0x303(#7)(AC-3)(deu)[PD]
[18:05:11.718] Teletext:
[18:05:11.734] PID: 0x20(deu_i100 )(#10)
[18:05:11.750] Subpict.:
[18:05:11.750] n/a
[18:05:11.750]
[18:05:11.781] !> missing sync. byte @ 0
[18:05:11.796] !> found sync. byte @ 3760
[18:05:11.953] ok> PID 0x20 has PES-ID 0xBD (private stream 1) (TTX) (4136 #3)
[18:05:11.968] ok> PID 0x303 has PES-ID 0xBD (private stream 1) (6580 #16)
[18:05:11.968] !> PID 0x1 (CAT) (7708 #22) -> ignored
[18:05:12.093] ok> PID 0x301 has PES-ID 0xC0 (MPEG Audio) (28388 #132)
[18:05:12.093] !> PID 0x1009 (ECM) (30644 #144) -> ignored
[18:05:12.093] !> PID 0x1648 (ECM) (30832 #145) -> ignored
[18:05:12.109] !> PID 0x66 (PMT) (51888 #257) -> ignored
[18:05:12.109] !> PID 0x0 (PAT) (56588 #282) -> ignored
[18:05:12.140] ok> PID 0x300 has PES-ID 0xC0 (MPEG Audio) (65612 #330)
[18:05:12.171] ok> PID 0x2FF has PES-ID 0xE0 (MPEG Video) (91744 #469)
[18:05:12.390] !> PID 0x11 (SDT) (516060 #2726) -> ignored
[18:05:12.843] -> video basics: 720*576 @ 25fps @ 0.7031 (16:9) @ 15000000bps, vbvBuffer 112
[18:05:12.843] -> starting export of video data @ GOP# 0
[18:05:12.843] !> dropping useless B-Frames @ GOP# 0 / new Timecode 00:00:00.000
[18:15:41.437] !> PID 0x20 -> packet 10729627 @ pos. 2017173448 out of sequence (2/1) (shifting..) (~00:55:55.120)
[18:15:41.437] !> packet writing: length index out of bounds, shortened.. (20 / bd / 90 / 83902 -- 552 / 46 / 690) @ PTS 00:00:00.000
[18:21:35.046] GOP# 10794, new format in next leading sequenceheader detected: (01:26:20.800)
[18:21:35.046] -> video basics: 720*576 @ 25fps @ 0.6735 (4:3) @ 15000000bps, vbvBuffer 112
[18:22:08.828] packs: 17045505 100% 3266543616
[18:22:08.843]
[18:22:08.843] -> Video: fr/ ct/ 1p/ cg/ og/ dg -> 134908/ 1/ 11243/ 11243/ 0/ 0
[18:22:08.968] -> Video length: 134908 frames @ 01:29:56.320
[18:22:08.968] -> GOP summary: min. 12, max. 24 fields; contains interlaced & progressive frames
[18:22:08.984] -> avg. nom. bitrate 3703289bps (min/max: 216000/9877200)
[18:22:08.984] -> set first sequenceheader bitrate to 9000000bps
[18:22:08.984] ---> new File: D:\temp\topfield\Große Haie - kleine Fische (Shark Tale).m2v
[18:22:09.218]
[18:22:09.218] --> using faked PTS for following data:
[18:22:09.312]
[18:22:09.312] --> Teletext on PID 0x20 (SubID 0x10)
[18:22:09.531]
[18:22:09.546] --> AC-3/DTS Audio on PID 0x303
[18:22:09.625] -> check CRC of AC-3 / MPEG-Audio L1,2
[18:22:09.625] -> delete CRC in MPEG-Audio Layer1,2
[18:22:09.640] -> add frames
[18:22:10.828] Audio PTS: first packet 04:27:07.711, last packet 05:57:04.831
[18:22:11.328] Video PTS: start 1.GOP 04:27:08.452, end last GOP 05:57:04.772
[18:22:11.406] -> adjusting audio at video-timeline
[18:22:11.453] -> src_audio: AC-3, CM, 2/0(2.0), dn -23dB, DS, 48000Hz, 384kbps @ 00:00:00.000
[18:22:11.484] -> src_audio: AC-3, CM, 3/2lfe(5.1), dn -27dB, cm -3.0dB, sm -3dB, 48000Hz, 384kbps @ 00:00:00.800
[18:22:19.906] !> CRC1 check failed @ 9271296
[18:22:19.921] !> missing syncword @ 9271298, @ 00:03:12.416
[18:22:19.968] !> found syncword @ 9272832
[18:22:19.984] !> 1 frame(s) (32ms) inserted @ 00:03:12.512
[18:23:19.718] !> CRC2 check failed @ 77761536
[18:23:19.734] !> missing syncword @ 77761538, @ 00:26:59.296
[18:23:19.781] !> found syncword @ 77763072
[18:23:19.796] !> 1 frame(s) (32ms) inserted @ 00:26:59.392
[18:24:01.406] !> CRC1 check failed @ 125978112
[18:24:01.406] !> missing syncword @ 125978114, @ 00:43:43.808
[18:24:01.468] !> found syncword @ 125979648
[18:24:01.468] !> 1 frame(s) (32ms) inserted @ 00:43:43.872
[18:25:47.406] -> src_audio: AC-3, CM, 2/0(2.0), dn -23dB, DS, 48000Hz, 384kbps @ 01:26:23.104
[18:25:57.921] audio frames: wri/pre/skip/ins/add 168635/0/0/3/0 @ 01:29:56.320 done...
[18:25:58.125] ---> new File: 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale).ac3'
[18:25:58.296]
[18:25:58.312] --> MPEG Audio (0xC0) on PID 0x301
[18:25:58.312] -> check CRC of AC-3 / MPEG-Audio L1,2
[18:25:58.312] -> delete CRC in MPEG-Audio Layer1,2
[18:25:58.312] -> add frames
[18:25:59.656] Audio PTS: first packet 04:27:07.785, last packet 05:57:04.905
[18:26:00.109] Video PTS: start 1.GOP 04:27:08.452, end last GOP 05:57:04.772
[18:26:00.140] -> adjusting audio at video-timeline
[18:26:00.203] -> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 192kbps, CRC @ 00:00:00.000
[18:30:56.031] audio frames: wri/pre/skip/ins/add 224846/0/0/0/0 @ 01:29:56.304 done...
[18:30:56.156] ---> new File: 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale).mp2'
[18:30:56.312]
[18:30:56.328] --> MPEG Audio (0xC0) on PID 0x300
[18:30:56.328] -> check CRC of AC-3 / MPEG-Audio L1,2
[18:30:56.328] -> delete CRC in MPEG-Audio Layer1,2
[18:30:56.343] -> add frames
[18:30:57.812] Audio PTS: first packet 04:27:07.833, last packet 05:57:04.953
[18:30:58.296] Video PTS: start 1.GOP 04:27:08.452, end last GOP 05:57:04.772
[18:30:58.312] -> adjusting audio at video-timeline
[18:30:58.359] -> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 192kbps, CRC @ 00:00:00.000
[18:32:04.968] !> CRC check failed @ 27747072
[18:32:04.984] !> missing syncword @ 27747074, @ 00:19:15.504
[18:32:05.000] !> found syncword @ 27747648
[18:32:05.015] !> 2 frame(s) (48ms) inserted @ 00:19:15.504
[18:36:09.234] audio frames: wri/pre/skip/ins/add 224846/0/0/2/0 @ 01:29:56.304 done...
[18:36:09.359] ---> new File: 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale)[1].mp2'
[18:36:09.375]
[18:36:09.375] summary of created media files:
[18:36:09.375] .Video (m2v): 134908 Frames 01:29:56.320 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale).m2v'
[18:36:09.375] Audio 0 (ac3): 168635 Frames 01:29:56.320 0/0/3/0 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale).ac3'
[18:36:09.390] Audio 1 (mp2): 224846 Frames 01:29:56.304 0/0/0/0 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale).mp2'
[18:36:09.390] Audio 2 (mp2): 224846 Frames 01:29:56.304 0/0/2/0 'D:\temp\topfield\Große Haie - kleine Fische (Shark Tale)[1].mp2'
[18:36:09.390] => 3.016.062.872 bytes written...
[18:36:09.406] -> we have 27 warnings/errors.

[Maliboy]

Code: Alles auswählen

[18:22:19.921] !> missing syncword @ 9271298, @ 00:03:12.416
[18:22:19.968] !> found syncword @ 9272832
[18:22:19.984] !> 1 frame(s) (32ms) inserted @ 00:03:12.512

Also, wenn ich das Lese, fehlt da ja ein komplettes Frame. Und wahrscheinlich setzt da der TOPFIELD aus.

Hast Du bei 0:26:59 und/oder bei 0:43:43 auch Tonaussetzer ?

[Gerti]

Hi!

Der Stream ist alles andere als i.O.

[18:22:19.984] !> 1 frame(s) (32ms) inserted @ 00:03:12.512
[18:23:19.796] !> 1 frame(s) (32ms) inserted @ 00:26:59.392
[18:24:01.468] !> 1 frame(s) (32ms) inserted @ 00:43:43.872

Das sollten Deine Aussetzer sein...
Am PC machen die vielleicht kein grossartiges Problem, einen AV-Receiver am Toppi können die aber schon aus dem Tritt bringen.

EDIT: Maliboy war schneller.

Gruß,
Gerti

[Varta]

Ich glaube, ich habe die Logdatei jetzt doch etwas besser verstanden. Da der Aussetzer ca. bei 0:03:13 anfängt, dürfte dies der relevante Teil der Logdatei sein:

[18:22:19.906] !> CRC1 check failed @ 9271296
[18:22:19.921] !> missing syncword @ 9271298, @ 00:03:12.416
[18:22:19.968] !> found syncword @ 9272832
[18:22:19.984] !> 1 frame(s) (32ms) inserted @ 00:03:12.512

Es fehlt also ein "Syncword" bei 00:03:12.416, aber das nächste Syncword wird ca. 13 tausendstel Sekunden später gefunden. Ein so kurzer Fehler muss nicht auffallen, siehe VLC.

Es fragt sich allerdings, warum der Topf darauf mit einem 6 Sekunden dauernden Tonausfall reagiert...

[Gerti]

Hi!

Nutzt Du bei VLC denn DD über einen AV-Receiver oder nur die Stereospur bzw. ein Downsampling?

Gruß,
Gerti

[Varta]

Jetzt wart ihr beide schneller, als ich mit meiner 2. Antwort : Und Danke für euren Support!

@Maliboy: ja, bei 0:26:59 und 0:43:43 sind auch Tonaussetzer, bei 0:26:59 nur sehr kurz, bei 0:43:43 mehrere Sekunden.

@Gerti: Verstehe ich es richtig, dass Du vermutest, dass es der AV-Receiver ist, der so lange zur Resynchronisierung braucht? Ich denke, dem ist nicht so. Wenn ich das optische Kabel abziehe und in den Stecker schaue, dann sehe ich, dass das rote Lichtsignal genau für die Dauer des Tonausfalls erlischt.
D.h. der AV-Receiver bekommt für die Dauer des Tonausfalls kein Signal vom Topfield. Sobald das Signal aber wieder anliegt, kommt auch ein Tonsignal aus dem Receiver. Die Zeit, die der Receiver selbst zum Resynchronisieren braucht, dürfe daher sehr kurz sein.

Die AC3-Spur habe ich mit VLC über den analogen Kopfhörerausgang abgehört. Das Audiodevice im VLC war auf 5.1 gestellt, aber was das genau bedeutet bzw. wie hier die Konvertierungspfade laufen, kann ich nicht sagen.

Gerne hätte ich den AC3-Ton über den opt. Ausgang der Soundkarte an den Receiver geschickt, aber das habe ich mit VLC bzw. Mplayer nicht hin bekommen (gibts noch was anderes?). Stattdessen habe ich dann die *.rec Datei mit DVR-Studio Pro auf DVD gebrannt. Ergebnis: Kein Tonaussetzer bei DD.

Wesentlich bedeutender finde ich allerdings den Umstand, dass für die Dauer des Tonausfalls sichtbarerweise kein AC3-Signal vom Topf geliefert wird. Für mich ist dies ein deutliches Zeichen dafür, dass der Grund für den langen Tonausfall beim Topf zu suchen ist.

Die Fragen, die sich mir jetzt aufdrängen sind:
1) ist es realistisch, 100% fehlerfreie Streams aufnehmen zu wollen?
2) läßt sich das beim Topf beobachtete, empfindliche Verhalten gegenüber Störungen verbessern?
3) reagieren andere Geräte (z.B. von Humax oder Technisat) auch so empfindlich auf Störungen?

[Gerti]

Hi!

Es kann durchaus sein, dass der Topfield auch diese Zeit zum Resynchronisieren des DD-Signals braucht, wenn Frames fehlen. Da der Fehler aber in Deinem Stream ist, dürfte es sich um eine Störung beim Empfang gehandelt haben. Ob andere Receiver da schneller sind, weiss ich nicht. Du solltest aber nicht versuchen die Wirkung zu kaschieren, sondern die Ursache zu beheben.

Gruß,
Gerti

[Varta]

Hi,

ich habe noch ein bischen herumprobiert, mit folgendem Ergebnis:

Die Zeit, die der Topf zum Resynchronisieren mit dem AC3-Ton benötigt, hängt anscheinend einzig vom Streaminhalt ab, nicht von der Art der Störung.

Wenn ich (ohne Störung) einfach in einer Aufnahme hin und her springe wird deutlich, dass der Ton immer an den selben, bestimmten Stellen wieder einsetzt. Wie lange es dauert, bis der Ton wieder einsetzt, hängt davon ab, wie weit es zur nächsten Stelle ist, an der der Ton wieder einsetzen kann.

Warum der Topf, im Gegensatz zum Stereoton bzw. zum Bild, nur an so seltenen Punkten mit dem AC3-Ton wieder einsetzen kann, ist mir unklar. Eigentlich ist AC3 für eine schnelle Resynchronisierung ausgelegt.

Wer es ganz genau wissen will, wird hier fündig: Digital Audio Compression Standard, Revision B

Die Idee, die Tonaussetzer dadurch zu vermeiden, dass die Störungen völlig eliminiert werden, hätte zwar einen gewissen Charme, ist bei mir aber leider nicht durchführbar, da ich bereits alle häuslich anwendbaren Möglichkeiten, insbesondere hochwertige Verkabelung sowie Justage des HF-Signalverstärkers am Verteilerpunkt, ausgeschöpft habe.

Hinzu kommt, dass man bei DVB prinzipiell mit einem gewissen Störungsanteil rechnen muss, da fehlerhafte Datenpakete nicht wiederholt werden können.

Ich frage mich zudem, ob eine Störungsrate von 3 verlorenen Frames in ca. 90 Minuten nicht schon ein ganz guter Wert ist. Prozentual sind ca. 0,00011 % der Frames fehlherhaft.

Vergleicht man dazu den prozentualen Anteil des fehlerhaften Tons, so sind es (bei ca. 10 Sek. Aussetzer in 90 Minuten) ungefähr 0,19 %, das ist etwa 1700 Mal soviel. Man könnte daher behaupten, dass der Topf aus einer "Störungsmücke" einen "Aussetzerelefanten" macht.

Letztlich werden auch Störungen des Bildes bzw. des Stereotons erfolgreich "kaschiert", d.h. auf ein Minimum reduziert. Das selbe würde ich mir für AC3 wünschen. Wenn es via Firmwareupdate ginge, wäre super, ansonsten würde ich es mir für die nächste Hardwaregeneration wünschen.

Wenn man Berichten in anderen Foren glauben darf, dann existert dieses Problem auch bei anderen Receivern - und dies seit Jahren. Schade eigentlich.

[freddy]

Ja,
wirklich schade daß es hierzu keine klare Aussage seitens Topfield gibt & daß da keine Lösung in Sicht ist.

Natürlich könnte das auch eine Störung durch DECT Geräte sein, ....
Dann könnte man evtl. den Topf irgendwie besser abschirmen.

Das scheint ja bei recht vielen Geräten aufzutreten, TF 4000, 5X000, .... egal ob Satelit oder Kabel, ...

Gibt es überhaupt ein Gerät von Topfield bei dem es diese Aussetzer nicht gibt ?

[longtom]

Hier eine Bespieldatei von mir:

!> CRC1 check failed @ 2912000
!> missing syncword @ 2912002, @ 00:00:51.584
!> found syncword @ 2913792
!> 1 frame(s) (32ms) inserted @ 00:00:51.712
!> 5 frame(s) (160ms) added @ 00:01:01.184
audio frames: wri/pre/skip/ins/add 1917/0/0/1/5 @ 00:01:01.344 done...

Warum wurden am Ende 5 frames dazugegeben?

Der Topf ist schon sehr heikel, schade....

[BartW]

Ich hatte auch Aussetzter in Verbindung mit DD-Ton. Bei mir war es ein billiges LWL-Kabel. Beim ersten Kabel hatte ich überhaupt kein Ton, beim zweiten Tonaussetzter und seitdem ich ein hochwertiges Kabel benutze sind die Aussetzter weg.

[Töppi]

[quote=""longtom""]....

Warum wurden am Ende 5 frames dazugegeben?

Der Topf ist schon sehr heikel, schade....[/quote]

Video & Audioframelänge sind normalerweise nicht identisch. Daher wird versucht durch Ergänzen von leeren Frames die Längen vom Audio dem Video anzupassen. Ist nix ungewöhnliches.
Da du ja auch 1 defektes Frame in der Aufzeichnung hast, ist es evtl. noch eines mehr.

[longtom]

[quote=""BartW""]Ich hatte auch Aussetzter in Verbindung mit DD-Ton. Bei mir war es ein billiges LWL-Kabel. Beim ersten Kabel hatte ich überhaupt kein Ton, beim zweiten Tonaussetzter und seitdem ich ein hochwertiges Kabel benutze sind die Aussetzter weg.[/quote]

Das Optische kabel ist es bei mir sicher nicht..

[BrainKoeln]

Hallo zusammen,

ich grabe diesen Thread nochmal aus weil ich unter den selben Problemen leide:
Wenn ich auf Premiere einen Film in DD5.1 gucke, gibt es etwa 5 bis 10 Mal kurze Tonaussetzer von einigen Sekunden. Stereo ist sauber. Anderere Receiver von TechniSat macht keine Probleme.

Gibt es derweil eine Lösung?

[Don_Krawallo]

Ich hatte auch jahrelang Probleme mit Dolby Aussetzern über Optokabelverbindung.
Mehrere verschiedene Boxen waren über diese Zeit im Einsatz.
Nach Anschaffung eines anderen AV Receivers waren diese völlig weg.
Es muss also nicht immer an der Box liegen / behebbar sein.