Beiträge von alexnoe

    Zitat

    AVI kann für einzelne Frames unabhängig eine Dauer speichern, soweit ich weiß... oder irre ich mich?

    Nein, kann es nicht. Man kann aber eine Framerate von 1000 fps einstellen und dann nach jedem Bild 39 Nullbilder einfügen, um 25fps zu erreichen (bedeutet 40-facher Overhead) und die Anzahl Nullbilder zwischen 2 Bildern varrieren... so kann man, vom Container her, quasi-vfr erreichen. Das macht ffmpeg auch, um Vorbis in AVI hineinzubringen.

    Wenn man sich in der von AVI-Mux GUI erstellten Datei die Bitrate ansieht, sieht man, dass AVI-Mux GUI eine Bitrate von 208 kbps "erzeugt" hat. Es war zwar eine interne Testversion, es zeigt aber, dass da etwas nicht i.O. ist, denn es ist soweit ich weiß gar nicht möglich, eine AC3 mit 208 kbps zu erzeugen...

    Ich glaube nicht, dass die AC3 fehlerhaft ist, sonst wäre es nirgends abspielbar.


    Zitat

    Habe mir allerdings noch mal die Settings des Aften-AC3 Encoders in BeHappy angeschaut und noch den Eintrag DPL Mode gefunden, den ich bis jetzt nicht gesetzt habe, liegt's da dran?

    Probier es doch mal aus...

    So, jetzt noch mal mit etwas mehr Zeit als auf Arbeit kurz vor der Mittagspause:


    Im AVI-Mux GUI - Ordner gibt es ein Profiles-Verzeichnis mit Dateien darin wie "Profile - Standalone AVI - AC3.amg". Diese können wie jede andere Datei geladen werden und setzen Einstellungen, die mit SAPs laufen sollten, für AC3 ist das: Open-DML aus, rec-Lists aus, relativ kleines Preload, relativ kleines Intervall, keine Verzahnung (d.h. z.B. 4 Bilder, 5 AC3 Frames, 4 Bilder, 5 AC3 Frames etc, d.h. 160 ms Video, 160 ms Audio,....), genau 2-3 AC3-Frames pro Chunk (genau 1 geht auf manchen Playern nicht).


    Zitat

    sowie (möglichst) den Index gleich am Anfang der AVI-Datei unterbringen (ein Grund für das Anlegen von JUNK-Chunks im Header


    Für AVI 1.0 ist das meines Erachtens nach unzulässig... für Open-DML ist es machbar, wenn man am Anfang schon weiß, wieviele Chunks entstehen werden. Nur ist Open-DML kein Thema, wenn es um SAPs geht. Des weiteren ist der Index beim sequentiellen Abspielen nicht nötig, es sei denn, das Headerflag AVIF_MUSTUSEINDEX ist gesetzt. Dann muss der Index benutzt werden, um die Reihenfolge zu ermitteln, in der Chunks abgespielt werden. Das ist z.B. wichtig bei low-overhead-Open-DML-Dateien, die aber interessieren noch viel weniger, wenn es um SAPs geht.

    GSpot ist ungeeignet, den AVI-Typ zu ermitteln. Es gibt zwei Unterschiede zwischen Open-DML und Legacy: ein zusätzliches Headerelement 'odml' sowie der Open-DML-spezifische Index.


    GSpot behauptet, es wäre ein Open-DML-File, sobald das odml-Element vorhanden ist, selbst wenn kein Open-DML-Index vorhanden ist.


    Grundsätzlich ist es mit VDub(Mod) unmöglich, Open-DML-Dateien < 2 GB zu erstellen. Ein Open-DML-Index wird ausschließlich erzeugt, wenn 2 GB überschritten werden.


    Für Standalone-Player gibt es Profile für AVI-Mux GUI. Wenn es trotz Verwendung eines solchen Profils nicht geht, dann brauche ich die Datei, die nicht geht. Nach Rücksprache per Mail schalte ich meinen Upload-FTP-Server an.

    Soweit ich weiß ist AC3 VBR und DTS VBR auf DVD-Videos nicht zulässig. Also dürfte auch keine korrekt funktionierende DVD-Authoring-Software zulassen, solche DVDs zu erstellen.

    Zitat

    nteressanterweise fügen Nandub, VirtualDub und VirtualDubMod auch "JUNK" ein. Klingt komisch, ist aber so.

    Tun sie, aber nicht *vor* den Headern, sondern erst in den Headern. M$'s AVI Splitter stört sich aber an dem *vor*. Das liegt einfach daran, daß die da wohl ihre eigene Spezifikation für AVI-Dateien nicht gelesen haben...

    Na ich sehe jetzt wirklich nicht, wo das Problem ist. Es steht doch wirklich alles da, und der Titel der Seite ist "ISO-9660:1999 Standard"... wenn Du meinst, daß es trotzdem kein Standard ist, dann Frag den Autor dieser Seite danach.


    Und was soll ich denn anderes machen als die interessanten Teile nochmal abzupasten und den Füllstoff wegzulassen, wenn eigentlich alles dasteht, es aber trotzdem nicht klar zu sein scheint...

    Der Schlüssel liegt in den "Extents", die ein "Stück" einer Datei darstellen. Deren Anzahl scheint nicht irgendwie begrenzt zu sein.


    Zitat

    Kann es sein, dass du eigentlich vom JIS X 0606:1998 redest, der aber (offensichtlich?) nie ISO-Standard wurde?

    Wie ist denn der Titel dieser Seite, also das, was der Browser in der Titelleiste des Festers anzeigt....


    Der Schlüssel liegt doch in

    Das heißt, man kann endlich viele 2 GB - Stücke erzeugen, für jede Datei:


    Richtig ist, daß Jörg da, vor 2 Jahren, noch nichts davon wußte, daß es so gehen müßte.

    Zitat

    Dann ist dieses ISO-9660:1999 Level ein aufgeborter Level (mkisofs: Creating ISO-9660:1999 (version 2) filesystem.) der nicht offiziell ist.

    Jetzt ist es offensichtlich: Du willst mich veralbern :)

    Zitat

    Und Nero kann auch ISO-9660:1999 erzeugen.

    Ja, seit kurzem, aber ein Volume-Label bis 31 Zeichen geht trotzdem nicht. Das geht nur mit mkisofs

    Zitat

    Laut Ahead handelt es sich dabei um ein systemunabhängiges und daher mit jedem System kompatibles Dateisystem.

    Eine offensichtliche Lüge. Der MP3-Player meiner Mutter kann das z.B. nicht, obwohl er ein "System" ist

    Zitat

    Bei einem ersten Test hat sich herausgestellt, dass das Dateisystem unter Windows XP problemlos lesbar ist.

    Unter 2K auch, NT vielleicht, Win 95 nicht.

    Du != alle folglich ist auch ~Du != niemand

    Zitat

    Also nach meinen Recherchen heute ist die Dateigröße bei ISO-9660 bis einschließlich Level 3 auf 2 GB limitiert!

    Abgesehen davon, daß ich ausdrücklich von ISO-9660:1999 geredet habe und nicht von irgendwelchen älteren Versionen ist es schon recht mutig, die Aussage von jemandem, der ein Programm zum Erzeugen solcher Images geschrieben hat als "haltlos" zu bezeichnen. Sicher *kann* es falsch sein, aber die Wahrscheinlichkeit dafür ist IMHO nicht soooo groß.


    Ich versuche mal von vorne:


    ISO-9660:1999 ist eine neuere Version von ISO-9660, die in mkisofs nur "-iso-level 4" heißt, weil das intuitiv ist, wenn es schon 1-3 gibt. Etwas wie "isolevel 4" gibt es nicht wirklich, weswegen ich die Frage, ob es so etwas gibt, schon viel weiter oben mit "nein" beantwortet habe.

    Was bistn du für einer? Zucker in den Kaffee PFUIIII


    Davon abgesehen ist auch der Rest deines Postings irgendwie sehr eigenartig, wahrscheinlich nimmst Du irgendwie dich und deinen komischen Player als Maßstab aller Dinge. Meine Eltern haben den billigsten DVD-Player, den es damals gab (Daytek irgendwas), da steht sowas im Handbuch drin... der kann ISO-9660 nur bis Level 2

    Mir egal, wie die Datei heißt. Als Quelle gibst Du ein Verzeichnis an, keine Datei. Sei deine Datei also im Verzeichnis d:\video


    mkisofs -iso-level 4 -V "<wie auch immer deine DVD heißen soll>" -o e:\image.iso d:\video


    Version ist die, die in cdrtools 2.01.01a03 dabei ist.

    Zitat

    Kannst du eine Quelle im Internet angeben (bitte mit Link)?

    Also www.iso.ch hat ein Rad ab (CHF 117 für den alten ISO-9660.... ), und ECMA hat nur den alten. Da muß ich erstmal ein bißchen suchen.

    Abgesehen davon, daß mkisofs es offensichtlich kann (kann man durch selber probieren überprüfen), stammt diese Aussage vom Author der cdrtools selbst. Im ISO9660:1999 Standard selber hab ich noch nicht nachgelesen, weil diese Dokumente meistens so geschrieben sind, daß es kein Mensch versteht