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.
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...
Äh, und?
Das heißt daß das bisher ungetestet ist.
Ich hab's aber auch mal mit einer DVD und der Original-ac3 in 48000kHz probiert, der Fehler ist der gleiche.
Dann liegt es wohl nicht daran...
Das ist eine AC3 mit 44.1 kHz. Ich glaube Du bist der erste, der so etwas jemals mit AVI-Mux GUI ausprobiert hat...
Es genügt ein Stück, mit dem sich das Phänomen reproduzieren lässt.
Bitte lade die Video- und die Audiodatei auf:
ftp://alexnoe.dyndns.org, Port 2000,
user upload
password only
Beachte, dass dort keine Löschrechte vorhanden sind. Dieses WE ist er allerdings offline.
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).
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.
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.
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
Da musst Du einen Multi-Extent Eintrag erzeugen: Für jeden Dateiteil
legst Du einfach einen Directory-Eintrag an. Jeder Dieser Einträge
beschreibt einen Dateiteil von 2 GB - 1 Sektor. Bei diesen Einträgen
muss das Multi-Extent bit (bit 7) der Dateiflags gesetzt sein. Nur
beim letzten Eintrag ist dieses Bit nicht gesetzt.Ich dachte, Du wuesstest das
Gruss Rainer
Das heißt, man kann endlich viele 2 GB - Stücke erzeugen, für jede Datei:
Das ganze nennt sich ISO 9660 Level 3. Level 3 erlaubt 'FileSections'.
Es spricht nichts dagegen, eine Datei zum Beispiel aus 4 FileSections
a 2 GB bestehen zu lassen. Dazu muss dann für diese Datei 4 mal der
gleiche Directoryeintrag gemacht werden. Bei den ersten dreien ist das
MultiExtent bit gesetzt und beim letzten nicht. Der Dateisystemtreiber
setzt dann diese Teile wieder zu einer grossen Datei zusammen.
Natürlich nur dann, wenn der ISO 9660 Treiber das kann. Windows kann
das ab Windows 2000
Richtig ist, daß Jörg da, vor 2 Jahren, noch nichts davon wußte, daß es so gehen müßte.
Da mußt Du ISO fragen... auf die Schnelle hab ich das gefunden
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 
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
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
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
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
Was steht denn im Handbuch des Players? 
Die Dateisysteme, die er lesen kann, sollten doch da drin stehen.
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.
Kannst du eine Quelle im Internet angeben (bitte mit Link)?
Also https://localhost/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
