Beiträge von Check It Out

Kann es sein, dass beim Bitsetting von +R/+R DL Unterschiede auftreten, je nachdem, ob das Bitsetting einzeln per Software (z.B. ImgBurn) vorgenommen wird oder pauschal fest per Firmware?

Grund der Frage ist die Kopie einer Navigations-DVD auf eine DVD+R.
Zuerst wurde mit ImgBurn ein Image der Original-DVD erstellt. Dann wurde mit einem LG-Brenner (H42L) eine Kopie gebrannt und dabei das Bitsetting auf DVD-ROM umgestellt (nur bis zum nächsten Neustart). Die Kopie wurde nicht als Original erkannt.
Anschließend wurde das Image mit einem LiteOn (20A1P, KL0P) gebrannt, mit dem Unterschied, dass die gepatchte Firmware grundsätzlich dauerhaft auf DVD-ROM gestellt ist. Die DVD wurde problemlos als Original erkannt.

Eigentlich wird doch dabei nur ein Bit auf dem Rohling verändert, was theoretisch brennerunabhängig geschieht. Scheinbar unterscheidet sich so ein Brand aber nicht nur hinsichtlich der Brennqualität, sondern die Brenner kochen ihr eigenes Süppchen, obwohl die Daten selbst bitidentisch sind.
Nicht umsonst findet sich im Netz oft der Hinweis, dass das Image nur mit Brennern z.B. von Pioneer funktioniert.

Benutzte Rohlinge waren von Verbatim (MCC004, Made in Taiwan) aus einer 50er Spindel.

Hat dafür jemand eine Erklärung?
Danke.

Ich werde jetzt noch versuchen, mit dem LiteOn mit einer unveränderten Firmware zu brennen, wo man ebenfalls extra auf DVD-ROM umstellen muss.

Bronimus, das Problem liegt an einer falschen Einstellung in ProjectX:
"konvertiere MPA : (2) 1-Kanal zu Stereo (L+R = Original)"
Du hast aber am Anfang 24 sek Stereo und erst danach Mono.
Richtig wäre Option 4 => Stereo zu 2*1 Kanal (L+R)
Dabei kommen am Ende zwei identische Monospuren heraus, von der man eine löschen kann und die andere dem TDA3 übergibt. Dann passt die angezeigte Lauflänge.

Goldwingfahrer, das ist eine Erkennungsschwäche des TDA3, weil du mit dem Procoder ein m2v im "exotischen" Field-Modus erstellt hast. Dabei werden in einem Frame die zwei Fields als zwei Bilder gespeichert, was beim TDA3 zur GOP-"Verdoppelung" führt. Das Video wird trotzdem sauber verarbeitet.

Bronimus, deine Audiodatei müsste ca. 134680 KB groß sein bei 95:46 Lauflänge und 192 kbps.
Die Lauflänge wird nicht ganz doppelt so lange angegeben. Kann es sein, dass nach wenigen Momenten tatsächlich 192 kbps Mono 1.0 enthalten ist und nur die ersten Frames noch Stereo sind. Einige Dritte Programme schalten da gerne zu um.
Wäre echt hilfreich, mal das komplette Log von ProjectX zu sehen, sonst kann man hier nur rumraten.
Oder einen Kurzschnipsel von ein paar MB hochladen (mit ProjectX vorgeschnitten!).

Goldwingfahrer, es geht hier um mpa/mp2 und nicht um wav (was bei DVB nicht vorkommt). Separat geladen hat Bronimus auch nicht, da beide Dateien im selben Ordner liegend identische Benennung vor der Dateiendung haben und TDA3 dann automatisch passend dazu sofort beide lädt.

Bronimus, das sieht für mich einfach aus, als wäre dein Audio im Vergleich zum Video deutlich zu lang.
Geh mal ins Schnittmenü und höre Anfang und Ende des Videos ab, ob der Ton dazu passt. Wenn der Ton nach dem Video z.B. nur aus Stille besteht, könnte man das Ende einfach abschneiden.

Im ProjectX Log solltest du überprüfen, ob die Lauflängen übereinstimmen, ähnlich wie es jpk999 gezeigt hat.
Den Ton könntest du auch mal in einen Mediaplayer laden um zu sehen, welche Lauflänge der anzeigt.

Bronimus, ich hoffe, du benutzt die aktuelle Version TDA 3.1.1.174. Dein Problem lässt auf die erste Version des TDA 3 (v3.0.5.149) schließen, die da einen bestimmten Bug hatte.

Ansonsten kann das Problem nur noch auftauchen, wenn du nicht DVD-konformes Material (v.a. bei der Auflösung) verwendest. Was sagt das Log von ProjectX zu deinen Dateien?
Die Projektdateien des TDA sind bisher nicht aufwärts kompatibel (nicht einmal kompatibel zur gleichen Version in einer anderen Sprache!).

Goldwingfahrer, was mb1 zu DVDlab vor 4 Jahren gesagt hat, hat doch heute x Versionen später gar keine Gültigkeit mehr! Und er empfahl doch immer den TDA, den du ebenfalls nicht magst

Infos zu Muxman findest du hier: http://www.mpucoder.com/Muxman/

Ich glaube, offiziell wird TDA 1.6 nicht mehr angeboten. Wenn du eine Registrierung auf der englischen Website anhand deiner Seriennummer vornimmst, kannst du die v1.6 herunterladen.
Bin mir nicht sicher, ob die Version noch mit einer 1.5-Seriennummer funktioniert. Weiß leider den genauen Funktionsunterschied zwischen 1.5 und 1.6 nicht mehr (lässt sich auf der offiziellen Seite auch nicht nachlesen).
EDIT: Download gibt es auch hier:
http://rbytes.org/freedownloads/…enc-dvd-author/
Musst halt schauen, ob der mit deiner Seriennummer geht.

Persönlich arbeite ich mit TDA3 ( gab es lange für unter 50 €) und bin damit weitgehend zufrieden. Man muss nur wissen, wie man kleinere Unzulänglichkeiten (die es aber in jedem Programm gibt) umschiffen kann.

Nun, daran liegt es.
Update wenigstens auf die letzte 1.6er Version ...

Die 1er Versionen sind bekannt dafür, sporadisch Streams abzuschneiden. Meistens (aber nicht nur) liegt das an geringfügigen Fehlern im Stream (z.B. Out of Bounds Fehlerinfo bei ProjectX), die Versionen ohne eingebauten Encoder abbrechen lassen.
TDA2/3 lässt das Problem kalt, sie encoden die entsprechende GOP in dem Fall neu.

Ach ja, externes Muxen vorab behebt das Problem nicht (immer).

Bronimus, welche Version (bitte genaue Versionsnummer) benutzt du?

Ich habe jetzt einen ruhigen Augenblick gefunden, in dem ich mich in die DV-Spezifikation, insbesondere den angesprochenen zusätzlichen Punkt 7.9 etwas einlesen konnte.
Die Blöcke, Makroblöcke und Videosegmente haben zwar eine vorgegebene Größe, deren Inhalt kann aber bei entsprechender Komplexität "überlaufen" und wird in den "unterforderten" Bereichen aufgefangen. Die reinen Daten eines Makroblocks können so zB größer als 77 Bytes sein, werden aber in 77 Byte Häppchen unterteilt.

Für mich ist das eine neue Erkenntniss und daher möchte ich mich bei scharfis_brain und cedocida für die Geduld bedanken. "Lernresistent" will ich schon gar nicht sein.

Ich hatte mir erst letztes Jahr im Herbst in der Bibliothek der TU München sämtliche verfügbaren Spezifikationen kopiert (DV, MPEG1/2, DVD usw) und danach "überflogen".
Dabei habe ich Punkt 7.9 bei DV - wahrscheinlich wegen des ganzseitigen Anordnungsalgorithmus - falsch verstanden, dahingehend, dass der nur dafür verantwortlich sei, wie die zusammengehörigen Makroblöcke in Videosegmenten ausgewählt werden.

Soweit ich das jetzt sehe, können Blöcke, Makroblöcke und Videosegmente "überlaufen". Erst Superblöcke bilden einen einheitlichen Abschluss. Was sich wo befindet steht dabei jeweils in einem Datensynchronisationsblock.
Vielleicht hilft das auch Anderen.

Zitat von cedocida

Genauer möchte auch ich nicht mehr werden

Das ist eben oft das Problem, wenn man gute Informationen bekommen möchte. An einem Punkt stoppen die Quellen im Internet "zugleich". Gut, manchmal ist man selber auch betriebsblind.

@ scharfis_brain
Habe im Anhang mal die Passagen aus der DV-Norm abfotografiert.

Variabel sind nur die Quantisierungen. Allein dadurch entsteht die unterschiedliche Qualität in entsprechenden Samples. Der große Textauszug vor ein paar Beiträgen beschreibt, dass so lange quantisiert wird, bis 77 Byte entstehen. Die Effizienzsteigerung entsteht aus der beliebigen Zusammenfassung gleicher bzw. ähnlicher Quantisierungen in 5er-Makroblöcken.

@ SixdeeBee
Ich wollte eigentlich nur Fehler richtigstellen. Beleidigt habe ich dabei nicht.

Die Antworten an simone.i wurden im Thread bereits gegeben:
- wurde DV in 4:3 aufgenommen, die DVD auch so erstellen. Bei richtiger TV-Einstellung gibt es am 16:9-Flach-TV links und rechts schwarze Balken.

- wird DV in echtem 16:9 aufgenommen, die DVD auch in 16:9 erstellen. Gibt Vollbild am 16:9-Flach-TV.

- wird DV in Pseudo 16:9 aufgenommen, kann man umrechnen. Wer sich aber nicht auskennt, sollte es lassen und am TV aufzoomen. Ansonsten für Anfänger zu viel Arbeits- und Zeitaufwand, sowie Fehlerquelle (interlace resize u.a.)

- hat man den seltenen Fall, dass man gemischte DV zu einer DVD bzw. einem einzigen Film zusammenstellen will, so muss man das 4:3-Material entsprechend umrechnen. Sollte man vermeiden.

Schade, dass niemand auch nur ein Minimum an falschen Einlassungen zugibt :nein:

@ cedocida

Und was sollte ich an der Aussage "Jeder Makro-Block hat 77 Bytes an Daten" und zugehörigem "Bild 37" in der Norm falsch verstanden haben?

Zitat

Die Europäische Norm EN 61834-2:1998 hat den Status einer Deutschen Norm.

Diese Norm enthält die deutsche Übersetzung der Internationalen Norm IEC 61834-2

Mir liegt nur die deutsche Übersetzung vor, die stimmt aber

Zitat von scharfis_brain

Check It Out: man sollte sich nicht immer auf nur eine einzige Quelle verlassen.

Wenn die DV-Norm diese Quelle ist, dann darf man sich schon darauf verlassen, denke ich.

Mal ein Auszug:

Zitat

7.8 Die Anordnung eines komprimierten Makro-Blocks

Ein komprimiertes Videosegment besteht aus fünf komprimierten Makro-Blocks. Jeder komprimierte Makro-Block hat 77 Bytes Daten. Die Anordnung des komprimierten Makro-Blocks muß sein, wie in Bild 37 gezeigt. Die Bereiche Y0, Y1, Y2, Y3, CR und CB sind als komprimierte Datenbereiche definiert, und jeder von Y0, Y1, Y2 und Y3 besteht aus 112 Bits, und jeder von CR und CB besteht aus 80 Bits.

Also nicht nur die Makroblöcke haben eine feste Größe, sondern auch die sechs Blöcke mit 4x14 Bytes und 2x10 Bytes. Hinzu kommen noch 4 Bits für den Zustand des komprimierten Makro-Blocks (STA) und 4 Bits für die Quantisierungsnummer (QNO), also das noch fehlende Byte zu den insgesamt 77 Bytes.

Genauer kann ich nicht mehr werden und Ihr dürft mir schon glauben :cheers:

Ich habe den Text schon richtig verstanden.
Entscheidend ist folgendes, was ich bereits erwähnte

Zitat von Check It Out

Schau einfach in die DV-Norm (EN 61834-2), Punkt 7.8: "Jeder komprimierte Makroblock hat 77 Bytes Daten".

Da steht es schwarz auf weiss und bietet keine Interpretationsmöglichkeiten.

Ach komm, Dein Sample interessiert mich nicht!

Schau einfach in die DV-Norm (EN 61834-2), Punkt 7.8: "Jeder komprimierte Makroblock hat 77 Bytes Daten".

Oder lies hiervon wenigstens den vorletzten Absatz:

[Blockierte Grafik: http://img442.imageshack.us/img442/6249/dvgrund1nz9.png]

Nur durch unterschiedliche Quantisierung der Makroblöcke und Zusammenfassung ähnlich quantisierter Makroblöcke sind Qualitätsunterschiede im Sample erreichbar. Der Makroblock hat trotzdem immer 77 Bytes.

Zitat von scharfis_brain

Die Makroblöcke haben unterschiedliche Quantisierungen und somit Datnmengen

Nein, eben nicht. Die Makroblöcke haben unterschiedliche Quantisierungen, damit sie gleiche Datenmengen bekommen!
Bei DV kann ein Makroblock eine von 64 unterschiedlichen Quantisierungen erhalten.
Im Ergebnis hat dann jeder Makroblock immer 77 Bytes.
Nun werden 5 ähnlich quantisierte Makroblöcke, die an den unterschiedlichsten Stellen im Frame liegen können, zu einem Superblock von 385 Bytes zusammengefasst usw.

Google einfach mal nach "77 Bytes" und "DV".

Zitat von scharfis_brain

weil der DV-Encoder mehr Datenrate auf die verbleibende Bildfläche verteilen kann

Das geht nicht. Bei DV hat jeder Makroblock immer die gleiche Datenmenge. Anders als bei MPEG kann daher in einfarbigen (zB schwarzen) Bereichen nichts gespart werden, was dann komplexeren Bildinhalten zugute kommen könnte.

Problem habe ich bestimmt keines.

Bei der Prozentrechnung kommt es auf den Basiswert an, also den Ausgangswert.

Zitat von SixdeeBee

576 Zeilen => 432 Zeilen resizen ... Verlust von Auflösung (33%)

Hier setzt Du als Basiswert 576 Zeilen mit Deiner Aussage. Um vom Basiswert auf die angepeilten 432 Zeilen zu kommen, sind 25% (= 144 Zeilen) abzuziehen. Endwert ist dann 432 Zeilen.
Bei Deiner Aussage zum Prozentwert springst Du plötzlich zu 432 Zeilen als Basiswert. 432 + 33,3% (144 Zeilen) = 576 Zeilen.

Also kurz und prägnant:
576 zu 432 entspricht 25% Verlust vom Basiswert 576.
432 zu 576 entspricht 33,3% Gewinn vom Basiswert 432.

Zitat von SixdeBee

576 Zeilen sind im Vergleich zu 432 Zeilen (= 4:3-Letterbox) 576/432 = 1,3333 => 33% mehr.

Genau! Zuvor sagtest Du noch 33% Verlust.

Und mit der Bildbreite verhält es sich ähnlich.
Ich nehme das tatsächliche gestreckte Bild (also 4:3 oder 16:9).
Wenn ich nur das aufgezeichnete Pixelbild sowohl bei 4:3 als auch bei 16:9 nehme, so bin ich sogar bei einem identischen Wert von jeweils 720x576 Pixel.

Zitat von SixdeeBee

Wie kommst Du auf 1,333 zu 1,777 ? Ein 720x576-Pixelbild hat ein Seitenverhältnis von 1.25 und nicht 1,333 .
Wenn Du 1,777 durch 1.25 teilst => kommt wieder 1.42 heraus.

Du wirfst alles durcheinander!
Ein 720x576-Pixelbild hat ein Seitenverhältnis von 1,25, vollkommen richtig. Aber auch die 16:9-Aufnahme bei DV besteht doch aus einem 720x576-Pixelbild. Das Aufnahmeseitenverhältnis ist also ebenso erst mal 1,25. :ja:
Erst jetzt kommt das Pixelseitenverhältnis ins Spiel, das die Entstreckung des 720x576-Aufnahmebildes bestimmt, um korrekte Endproportionen zu bekommen.
Da hat 4:3-DV übrigens ein 128/117 Pixelseitenverhältnis, also ~1,094 (720 Pixel werden zu 788 Pixel entstreckt, nicht zu 768).
Und 16:9-DV hat ~1,4587 (720 Pixel werden zu 1050 Pixel entstreckt, nicht zu 1024).

Aber genug davon. Einigen Lesern dürfte bereits der Kopf brummen ob des Zahlenwirrwarrs.

Da hat es Einer aber nicht so mit der Prozentrechnung - und das trotz Herumwerfens mit jeder Menge Zahlen. :ani_lol:

Zitat von SixdeeBee

daß gegenüber 4:3 damit 42% mehr Bildbreite zur Verfügung steht

1,333 zu 1,777 sind 33,3% mehr Bild.

Zitat von SixdeeBee

576 Zeilen => 432 Zeilen resizen ... Verlust von Auflösung (33%)

576 zu 432 sind 25% Verlust.

Vielleicht die Trace-Funktion in PGCedit ...

Du kannst beim TDA3 in den Enkodiereinstellungen die Grundeinstellung "Normale Genauigkeit" auf "Schnellerkennung" einstellen. Das sollte die Geschwindigkeit etwa verdoppeln.

Außerdem berechnet der TDA3 am Anfang die Bewegtmenüs, da kommt es ganz darauf an, was du eingestellt hast.
Bei mehreren Hauptmenüs (weil 10 Folgen kaum auf eine Menüseite passen) und evtl. noch für jede Folge einem bewegten Trackmenü dauert die Menüberechnung "ewig". Vor allem, wenn ein Bewegtmenü vielleicht noch mehrere Minuten dauern soll ...
Da wundert es dann nicht, wenn ConvertXtoDVD schneller ist, hat ja nicht mehrere Bewegtmenüs zu berechnen.